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ABSTRACT 
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This  report  focuses  on  command  and  control 

2 

(Cj)  system  capabilities  at  the  force  management 

level  within  the  Air  Force  contingency  Tactical  Air 

Control  System  (TACS).  An  investigation  of  the 

2 

primary  force  level  Cu  system  identifies  serious 

deficiencies  impacting  on  the  Air  Force  Forces 

“fATFORT  commander's  ability  to  manage  tactical  air 

forces  in  a  conflict  environment.  This  system  can 

meet  neither  the  commander's  present  nor  his 

projected  future  operational  needs. 

This  report  outlines  an  evolutionary 

acquisition-  approach  toward  fielding  a  replacement 

2 

system  in  the  near  term  and  providing  a  core  C^ 
system  upon  which  future  capabilities  must  evolve  as 
technology  and  requirements  change.  A  test  bed 
based  Requirements  Definition  Study  Period  CRDSP) 
project,  managed  by  Headquarters,  Tactical  Air 
Command  (HQ  T.^C) ,  is  specified  as  the  solution  to  ~ 
the  rapid,  accurate,  and  intelligent  specification  s,| 
of  core  system  requirements.  .d 

The  exploitation  of  the  proven  capabilities 


of  evolving  Army  and  Marine  tactical  operational  ^ . - . 

test  bed  systems,  studied  in  this  report,  is  — ^ -tity  Codes 


S>vdii  a  .d/or 
I  Special 


□  □ 


considered  basic  to  the  RDSP  undertaking.  The 
recommended  strategy  is  aimed  at  not  only  fielding 
an  effective,  adaptive  tactical  Cy  system  but  at 
addressing  ^b^th  TAGS  and  joint  architecture 

/I 

(I 

Through  the  RDSP  HQ  TAG  will  be  able  to 
begin  seriously  defining  its  TAGS  architecture. 
Identifiable,  visible  progress  in  the  definition  of 
joint  architecture  can  be  made  through  "hands-on" 
exercise,  test,  and  evaluation  of  user  requirements, 
employing  the  systems  described  in  this  report. 
Meaningful  progress  in  solving  the  interoperability 
problem  will  not  be  made  until  joint  architecture 
requirements  are  better  defined.  Paper  studies  and 
laboratory  experiments  will  not  by  themselves 
suffice. 


He  in  this  report  is  used  in  the  generic 


sense. 
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CHAPTER  I 


INTRODUCTION  AND  OVERVIEW 


The  greatest  challenge  we  face  is  continuing  to 
deter  Soviet  aggression  across  the  conflict 
spectrum- - from  conventional  through  strategic 
nuclear.  On  the  conventional  side,  we're 
strengthening  deterrence  by  improving  the 
readiness  and  capability  of  our  forces. 

--Gen  Charles  A.  Gabriel 


The  Conflict  Bandwidth 

The  rate  of  advancement  of  information 

systems  technologies  renders  command  and  control 
2 

CC  )  systems  that  cannot  evolve  to  keep  pace  with 

2 

their  change  quickly  obsolete.  C  systems  that  are 
too  inflexible  to  adapt  to  the  range  and  dynamic 
nature  of  a  commander's  operational  needs  are  worse 
than  inferior:  they  are  themselves  potential 

killers . 


Conventional  Conflict 

Modern  technology  has  produced  a  land  and  air 
battlefield  that  is  on  one  hand  greatly  expanded  due 
to  the  range  of  modern  weapons;  on  the  other  hand, 
the  decision  cycle  of  the  commander  has  been 
dramatically  compressed  by  the  speed  and  accuracy  of 
modem  delivery  platforms,  .^alyses  of  the  future 


2 


conventional  battlefield  sketch  an  environment  even 

more  fluid  and  destructive  than  that  imaginable 

today.  The  importance  of  salient  operational 

features  (e.g.,  survivability,  flexibility,  and 

reliability)  of  C  systems  will  increase 

concomitantly  with  the  requirements  for  more 

2 

powerful  and  complex  C  system  capabilities. 

The  Subconvent ional  Arena 

The  so-called  "conflict  bandwidth"  has 
widened  within  the  last  20  years,  the  battlefield 
mentioned  above  being  only  one  scenario.  Figure  1.1 
depicts  this  changed  nature  of  conflict.^ 

Subconventional  conflict,  though 
appreciably  less  threatening  to  the  United  States' 
security  than  either  conventional  or  nuclear 
conflict,  is  shown  to  be  far  more  likely  to  occur. 
Shows  of  force  (deployments  to  Egypt  and  Sudan) , 
terrorism  (Iran  and  Beirut),  counter-insurgency 
operations  (Central  America)  and  low  intensity 
operations  (Grenada)  all  exemplify  the  types  of 
scenarios  in  which  the  U.S.  has  had  to  operate  in 
very  recent  years. 

Missions  on  this  end  of  the  conflict 
band  have  typically  been  time-sensitive  and  highly 
visible.  During  operations  in  areas  of  the  world 
not  having  extensive  U.S.  information  systems  (e.g.. 


FIGURE  1.1  THE  CONFLICT  BANDWIDTH 
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in  the  U.S.  European  and  Pacific  Command  regions), 

2 

C  has  immediately  emerged  as  an  overriding  issue  in 

2 

force  management.  C  inadequacies,  to  include 
interoperability  failures,  have  also,  unfortun¬ 
ately,  surfaced  in  the  aftermath  of  such  operations. 
General  Robert  Herres  stated  in  1984: 


A  well  managed  crisis  is  no  more  than  a 
brief  incident,  while  a  badly  managed 
situation  inevitably  results  in  tragedy  and 
conflict.  The  planning  aids,  communi¬ 
cations  devices  and  other  tools  our 
leadership  uses  to  deal  with  these  tense 
situations  can  2be  the  difference  between 
these  extremes, 
i 

2 

C  sys-tems  have  not  been  fielded  to 
adequately  support  an  Air  Force  Forces  (AFFOR) 
conmiander ' s  management  of  contingency  tactical  air 
forces . 


2 

C  and  the  Tactical  Air  Control  System 
C^  Systems 

This  report,  using  the  Armed  Forces 
Communications  and  Electronics  Association 
definition,  defines  Command  and  Control  systems  as: 


Those  systems  that  augment  the  decision-making 
and  decision-executing  processes  of  operational 
commanders  and  their  staffs.  The  central, 
essential  ingredient  in  any  command  and  control 
system  i^  the  commander  or  decision  maker 
himself. 


This  definition  differs  from  that  of  the  Department 

of  Defense  (DoD) ,  which  has  excluded  the  commander 

in  its  definition  (see  glossary). 

2 

C  systems  are  generally  distinct  from 

weapons  systems  and  must  be  acquired  differently. 

Reputable  studies,  feelings  among  senior  military 

leaders,  and  the  egregious  consequences  of  acquiring 
2 

C  systems  through  traditional  processes  amply 

2 

support  this  fact.  C  systems,  for  example: 

1.  Are  characterized  by  rapidly  evolving 
technology. 

2.  In  many  cases  must  be  tailored  to  specific 
environments,  be  one-of-a-kind.,  support 
individual  commanders,  and  be  required  to 
readily  adapt  to  changing  operational 
needs . 

3.  .Above  all,  are  systems  whose  operational 
essence  and  costs  are  dominated  by  an 
intangible- -software. 

.An  evolutionary  approach  is  the  appropriate 

2 

strategy  through  which  to  acquire  C  systems. 

This  report  examines,  in  the  following 
chapter,  an  evolutionary  acquisition  (E.A)  model  and 
present  guidance  and  policy  from  the  DoD  and  the  .Air 


The  Tactical  Air  Control  System,  or  TAGS, 
is  an  integral  and  inseparable  part  of  the  AFFOR 
commander's  fighting  force.  It  is  the  Air  Force 
system  through  which  he  exercises  centralized 
command  and  decentralized  force  control. 

The  senior  element  within  the  TAGS  is  the 

Tactical  Air  Control  Center  CTACC) ,  the  AFFOR 

2 

commander's  tactical  command  center.  C  functions 
within  the  TACC  are,  in  1985,  still  predominantly 
manual,  inefficient,  and  very  labor-intensive. 

The  most  critical  document  in  the  TAGS  is 
the  Air  Tasking  Order,  or  ATO.  The  .\T0  (previously 
called  the  "frag")  is,  basically,  a  mission  tasking 
order,  directed  to  the  commander's  subordinate 
elements,  detailing  the  types  of  missions  to  be 
performed  and  the  targets  to  be  attacked. 

Excluding  automated  support  employed  by  the 
intelligence  functions  within  the  T.^CC,  the  only 
automated  assist  to  the  AFFOR  commander's 
decision-making  and  decision-executing  processes  is 
the  Computer  Assisted  Force  .Management  System 
(C.^FMS).  Its  principal  use  is  to  assist  the 
operations  and  planning  functions  in  "building"  and 
disseminating  the  ATO. 


CAFMS  caul  meet  neither  the  ccHnmander '  s 
present  nor  his  future  operational  requirements. 

This  report  finds  CAFMS  to  be  marginally 
deployable,  inflexible,  unsustainable,  highly 
vulnerable  and  of  questionable  reliability. 
Further,  CAFMS  has  never  achieved  Initial 

2 

Operational  Capability,  yet  it  is  the  force  level  C 
system  in  the  TACS.  Chapter  III  reports  on  an 
inspection  of  CAFMS. 

There  are  no  funded  programs  to  address 
this  serious  deficiency. 

T.ACS  Architecture 

Billions  will  be  spent  over  the  next 
several  years  to  acquire  and  field  various  elements 
of  the  TACS.  A  piecemeal  system  of  "things"  is 
currently  destined  to  transpire,  and  these  thing- 
oriented  programs  have  been  retroactively  fitted 
into  an  ill-defined,  complex,  and  very  confusing 

4 

"roadmap"  to  the  future  (see  Chapter  IV).  There  is 
presently  no  realistic  T.4CS  architecture,  as  such; 
it  is  more  a  collection  of  individual  systems. 

Headquarters,  U.S.  Air  Force  has,  since 
spring  1985,  directed  the  development  of  technical 
and  functional  information  systems  architectures  to 
guide  development  and  integration  of  information 


systems.  Table  1.1  highlights  the  general  trends 

that  will  affect  Air  Force  information  systems.^ 

Defining  future  TAGS  architecture  (see 

"architecture"  in  glossary)  will  be  a  difficult  and 

complex  undertaking.  The  "mixed  bag"  of  present  and 

planned  programs  within  a  1960s -vintage  TAGS,  the 

2 

characteristics  of  G  systems,  and  the  extreme 
difficulty  in  articulating  future  requirements,  in 
addition  to  these  "general  trends"  are  a  few 
complicating  factors. 

Architecture  development  for  the  TAGS  must 
begin  at  the  force  management  level. 

This  Report 

Recommendations 

The  thrust  of  this  report  is  a  series  of 
recommendations  in  Ghapter  IV  through  VIII: 

1.  To  correct,  in  the  near  term,  force 

2 

level  operational  readiness  and  G  system 
deficiencies . 

2.  To  articulate  the  requirements  of  a 

2 

"core"  force  level  G  system  into  which  future 
improvements  can  and  must  be  integrated. 

3.  To  establish  a  starting  point  for  and 


begin  definition  of  TAGS  architecture. 
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1. 

2. 


3. 


4. 


5. 


TABLE  1.1 

OVERALL  TRENDS  INFLUENCING  AIR  FORCE 
INFORMATION  SYSTEMS 


Mission-essential  information  requirements 
are  growing  rapidly. 


The  increasing  stresses  of  modern  combat 
adversely  affect  the  capability  and 
capacity  of  information  systems  to  satisfy 
essential  requirements. 


Technology  continues  to  advance  at  an 
extremely  high  rate. 


Total  funds  spent  on  information  systems 
are  rising  due  to  the  high  increase  in  the 
rate  of  applying  automation  to  previously 
manual  processes  and  upgrading  previously 
automated  processes;  the  increase  in  total 
user  requirements  more  than  offsets  the 
declines  in  unit  cost  resulting  from 
technology  advances. 


Systems  are  becoming  too  complex  to  permit 
radical  change;  evolutionary  improvements 
are  required. 


iw  w!  iwiw  w.’ iftwnw  w  wwuvfww  wvvvvri 
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A  decisive  EA  strategy  is  the  essential 

• 

means  through  which  this  may  be  accomplished,  with  a 

requirements  definition  study  period  (a  test  bed)  as 

the  precursor  of  the  fielded  system.  This  report 

examines,  in  Chapter  VI,  EA  approaches  toward 

requirements  definition  for  Army  and  Marine, 

2 

tactical  C  test  bed  systems  (and  a  planned  Air 
Force  system  in  Europe).  Software,  hardware,  and 
system  capabilities  are  discussed. 

This  repoxi:  considers  the  exploitation  of 
the  proven  capabilities  of  these  systems  to  be  sine 
qua  non  to  the  timely  establishment  of  an  effective 
system  in  the  near  term. 

A  Case  for  .'Vddressing  Interoperability 

When  VAdm  Jon  L.  Boyes,  USN  (Ret.)  reported 
in  the  November  1985  SIGNAL  the  threat  from  Senator 
Goldwater  (R-.^Z)  to  restrict  money  for 
communications  equipment  "until  meaningful  progress" 
was  made  in  interoperability,  he  conveyed  an 
unmistakable  message  from  Mr.  Goldwater:  DoD  must 
begin  fixing  interoperability.^ 

Serious  effort  in  tackling  the  dynamic, 
increasingly  complex  interoperability  problem  began 
only  last  year  with  the  creation  of  the  Joint 
Tactical  Command,  Control,  and  Communications  Agency 
(JTC  A.),  under  the  command  of  Major  General 
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Archibald,  USA.  JTC^A's  job  is  to  ensure  inter¬ 
operability  of  tactical  systems;  its  primary 
mission  has  been,  as  a  means  to  achieve  this  goal, 
joint  architecture  development.  The  "generic  joint 
mission  area  architecture,"  a  baseline  architecture 
currently  under  development,  is  a  synthesis  of  the 
various  service  planning  guides,  such  as  T.^C's 

7 

present  "roadmap." 

Paper  studies  and  laboratory  experiments  by 
themselves  will  not  provide  "meaningful  progress" 
toward  solving  the  problem. 

This  report  suggests  that ,  through 
"hands-on,"  user-controlled  exercise,  test,  and 
evaluation  of  the  systems  described  in  Chapters  VT 
and  VII,  a  genuine  leap  toward  defining  Unified 
Command  architectural  requirements  could  be  made  in 
the  near  terra.  The  immediate  benefit,  as  the  reader 
will  note,  will  go  to  the  United  States  Central 
Command. 

The  test  bed  systems  examined  in  Chapter  VI 

are  the  beginning  of  "innovation  and  common  sense" 

2 

in  C  requirements  definition  and  architecture 

g 

development . 

JTC^A  can  gather  invaluable  data  from  such 
an  approach.  Other  benefits  include  more  realistic 


operations  planning  and  doctrine/procedures 
development . 


12 


13 


REFERENCE  NOTES 
CHAPTER  I 


^Gregory  D.  Foster,  "Conflict  to  the  Year 
2000,"  Air  University  Review  36  CSeptember-October , 
1985):  TT. 

^Lt  Gen  Robert  Herres ,  USAF ,  "C^I  in  Crisis 
Management:  Secure  Voice  Capability,"  SIGNAL,  May 
1984,  p.  38. 

^Armed  Forces  Communications  and 
Electronics  Association  (AFCEA) ,  Command  and  Control 
System  Acquisition  Study  Final  Report  [Falls  Church , 
VA,  1  September  19^2),  p.  1-10. 

"^The  term  "things"  has  been  borrowed  from 
VAdm  Jon  L.  Boyes ,  USN  (Ret.),  who  discusses  the 
procurement  of  "things"  vs.  procurement  of  systems 
in  "The  Need  to  Discipline  C^I  User  Requirements," 
SIGN.M.  May  1985,  p.  20. 

^U.S.  Department  of  the  .4ir  Force, 
Headquarters,  U.S.  .4ir  Force,  Air  Force  Information 
Systems  .Architecture,  Volume  I--Overview 
(Washington ,  D.  C.  ,  S  May  198  5) ,  p.  1  -T. 

^  ^V,4dm  Jon  L.  Boyes,  USN  (Ret.),  "Tactical 

C^I  Interoperability  and  the  Somme,"  SIGN.4L, 
November  1985,  p.  16. 

^William  J.  Blohm  and  Lt  Col  William  R. 
Brown,  US.4F,  "Joint  Tactical  C"^  .Architecture," 
SIGN.AL ,  November  1985  ,  p.  53. 

Q 

"Innovation  and  common  sense"  may  be  found 
under  "Acquisition  Strategy"  in  appendix  C,  Extracts 
from  Defense  .Acquisition  Circular  76-43. 


I 

I 


CHAPTER  II 


EVOLUTIONARY  ACQUISITION 

Men  alone,  or  machines  alone,  do  not  spell 
success:  how  men  use  machines  in  the 
combat  environment  and  the  spirit  of 
leadership,  that  guides  that  use,  spell 
victory  or  defeat. 

- -Basic  Areospace  Doctrine 

General  Definition  of  Evolutionary  Acquisition 

Growing  concern  among  senior  military 

leaders  that  command  and  control  systems  are 

different  from,  and  should  be  acquired  differently 

than,  weapons  systems  is  beginning  to  be  reflected 

in  DoD  and  Air  Force  guidance  and  policy. 

Evolutionary  Acquisition,  or  simply  EA,  is  an 

alternative  strategy  that  recognizes  the  uniqueness 
2 

of  C  systems.  Creditable  studies  have  articulated 

these  unique  characteristics.  No  command  and 

control  systems  acquired  via  the  traditional,  serial 

approach  have  been  considered  successful.  The 
2 

nature  of  C  systems,  the  rate  of  changing 
technology  and  requirements,  and  the  glacial  speed 
of  "business  as  usual"  are  but  a  few  reasons  for 
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Evolutionary  Acquisition  is  a  system 
acquisition  strategy  in  which  the  user  identifies  an 
overall  system  requirement  in  general,  functional 
terms.  A  detailed  description  of  a  "core  increment" 
is  developed,  and  the  system  is  fielded  within  a 
flexible  framework  allowing  for  evolutionary  growth. 
EA  is  thus  an  adaptive  strategy.  As  experience  is 
gained  from  the  operational  use  of  the  core 
increment  the  subsequent  increment  is  defined, 
funded  (within  an  overall  system  budget) ,  developed, 
fielded,  and  user-tested.  The  process  goes  on;  it 
is  iterative. 


Subsequent  increments  or  "blocks"  are 
defined  sequentially,  based  on  continuing 
feedback  provided  from  lessons  learned  in 
operational  usage,  concurrent  evaluation  of 
adequacy  of  hardware/software  configuration,  and 
judgments  of  improvements  or  increased  capa¬ 
bilities  that  can  result  from  application  of  new 
technology,  where  feasible. 


EA  and  Pre-planned  Product  Improvement 

(P^I)  are  different  concepts,  the  basic  difference 

being  that  P^I  does  not  require  the  user  to  accept 

significant  responsibility  in  system  acquisition. 

The  similarities  and  differences  between  E.\  and  P^I 

2 

are  revealed  in  appendix  C. 
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The  EA  Model 

Figure  2.1  indicates  a  basic  EA  model, 
depicting  EA's  incremental  Cand  overlapping) 
process,  as  extracted  from  the  September  1985 
article  in  SIGNAL  by  BGen  Edward  Hirsch,  USA 
(Ret.). ^ 

The  user  is  continuously  involved 

2 

throughout  the  life  of  the  C  system,  as  new 

capabilities  are  fielded  and  the  system  evolves. 

One  of  the  fundamental  differences  between  EA  and 

2 

traditional  methods  is  that  the  C  user  is 
recognized  as  a  significant -to-dominant  player  in 
the  requirements  process,  and  the  results  of  user 
testing  are  fed  into  specifications  of  all 
increments . 

With  EA  the  requirements  definition  process 
extends  throughout  a  system's  lifetime.  Implicit  in 
this  approach  is  a  much  closer  and  less  formal,  con¬ 
taining  relationship  among  user,  development,  and 
testing  communities,  throughout  the  ongoing  process. 
To  summarize  the  basic  EA  model: 

1.  The  user  describes  an  overall,  general, 

2 

functional  C  requirement.  Working  with 
the  developer  he  defines  the  specific 
requirements  of  a  core  increment.  The 
basis  of  this  may  be  a  test  bed  or 


prototype.  The  core  is  an  operationally 
usable  system. 

The  developer  designs  a  preliminary, 
overall  system  architecture  that 
facilitates  incremental  growth  throughout 
the  system's  life. 

The  core  increment  is  developed  and  fielded 
with  near  term  funding.  User,  developer, 
and  tester  are  involved  in  the  acceptance 
of  the  system  by  the  user. 

Feedback  is  provided  into  the  definition  of 
the  next  increment,  based  on  the  user's 
exercise  of  the  system  in  the  operational 
environment . 

Definition  of  the  next  increment,  reports 
of  user  satisfaction,  and  overall  program 
management  provide  the  basis  for  funding 
(within  an  overall  "fenced"  budget)  of  the 
next  increment.  The  process,  rather  than 
being  sequential,  is  overlapping. 

.Architectures  that  cannot  be  defined  with 
high  specificity  initially  may  have  to  be 
modified  later.  The  architecture  is  an 
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essential  element  and  must  be  given  great 
care. 


Background 

Two  major  studies  have  provided  the 
groundwork  for  present-day  policy  governing  EA:  one 
from  the  Defense  Science  Board  [see  glossary)  Task 
Force  on  Command  and  Control  Systems  Management,  the 
other  from  the  Armed  Forces  Communications  and 
Electronics  Association. 

The  DSB  Task  Force 

The  DSB  Task  Force  was  commissioned  in  1977 
to  examine  whether  or  not  the  United  States  was 
acquiring  command  and  control  systems  capabilities 
commensurate  with  weapons  systems  being  deployed  and 
with  the  United  States'  available  technological  and 

4 

industrial  base.  The  major  conclusion  reached  by 

2 

the  Task  Force  indicated  a  serious  deficiency  in  C 

systems  acquisition,  and  its  Command  and  Control 

Systems  Management  Report  determined  that  the 

existing  direction  in  systems  acquisition  was  not 

applicable  to  command  and  control  systems.^  Command 

and  control  systems  were  found  to  differ  in  several 

critical  respects  from  weapons  systems,  one  of  which 

is  the  "information  rich,"  software  dominant 
2 

features  of  C  systems.  The  report  stated  "acqui- 
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sition  procedures  based  on  hardware  have  little  a 

priori  applicability  to  command  and  control 

systems."  Subsequent  to  the  DSB's  report  DoD 

directives  and  instructions  were  modified  to  allow 

2 

"special  management"  procedures  in  C  system 
acquisit ion . 

The  AFCEA  Study 

The  Armed  Forces  Communications  and 

2 

Electronics  Association  Command  and  Control  (C  ) 

System  Acquisition  Study  was  the  first  major  effort 

2 

to  study  what  it  is  about  C  systems  that  are 
different  from  weapons  systems,  what  impediments  had 
been  preventing  EA  from  being  successfully 
implemented,  and  what  actions  were  required  to 
successfully  implement  EA.  ^ 

BGen  Edward  Hirsch,  US.\  (Ret.)  has  stated: 

The  credentials  of  the  study  group  members 
are  unassailable  and  impressive,  the 
research  effort  is  formidable;  the 
arguments  are  articulately  and  lucidly 
presented,  the  logic  of  its  conclusions  is 
compelling;  and  the  recommendations  are 
sound. 

The  key  personnel  involved  in  the  .^FCEA  study  are 
shown  in  Figure  2.2. 

2 

The  study  team  found  n£  successful  C 
programs  where  the  traditional  acquisition 
(Milestone  I,  Milestone  II,  etc.)  process  had  been 
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followed.  Among  the  more  obvious  failures  was  a 

program  to  automate  the  Tactical  Air  Control  Center, 

called  TACC  AUTO  (see  Chapter  III).  The  team 

disclosed  that  EA  had  not  been  aggressively  applied 

and  that  there  was  great  resistance  among  the  formal 

Research  and  Development  (RSD)  communities  to  deal 

with  what  the  study  team  chairman  has  referred  to  as 

0 

"deviant  behavior."  Evolutionary  Acquisition  was 
also  found  to  be  not  well  understood,  particularly 
among  senior  officers  in  the  user  arena. 

The  AFCEA  study  team's  overall  conclusions 

9 

are  shown  in  table  2.1. 

2 

Characteristics  of  C  systems 

Command  and  control  systems,  termed  "mind 

extending"  systems  by  the  AFCEA  study  team,  are 

2 

actually  decision  support  systems.  C  must 
integrate  the  needs  of  a  commander  with  the 
realities  of  his  operational  environment  and  help 
the  commander  decide  various  courses  of  action  to 
take  in  the  employment  of  his  forces.  The  DSB  Task 
Force  report  states: 

The  absence  of  commonly  understood  concepts 
of  command  and  control  system  performance 
and  the  existence  of  language  barriers 
among  technologists,  policy  analysts, 
planners,  and  commanders  all  underlie  the 
fact  that  we  in  DoD  lack  any  very  useful 
conceptual  framework  for  evaluating  Oji^ 
specifying  command  and  control  systems. 


I 
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TABLE  2.1 

MAJOR  CONCLUSIONS  OF  THE 
AFCEA  C^  SYSTEM  ACQUISITION  STUDY 


1.  Evolutionary  Acquisition  gives  a  much 

higher  probability  that  a  useful  military 
capability  will  be  fielded  earlier. 


2.  Although  Evolutionary  Acquisition  is  policy 
for  C^  systems,  its  application  is  spotty 
and  it  is  not  well-defined  and  understood. 


3.  Evolutionary  Acquisition  will  not  work  on  a 
"business  as  usual"  basis,  yet  acquisition 
support  communities  (e.g.,  requirements 
validation,  budgeting,  contracts, 
"ilities,"  test)  discourage  approaches 
deviant  from'  the  traditional  approach. 


4.  Successful  Evolutionary  .Acquisition 
requires  continuous  interaction  among 
users,  providers  and  testers  and  a  more 
influential  role  by  the  real  user. 

2 

5.  A  potential  for  chaos  exists  if  C  system 
acquisition  proceeds  without  an 
architectural  framework,  including 
flexibility  to  facilitate  growth. 


The  dominant  role  of  software.  Command  and 


control  systems,  unlike  weapons  systems,  are 
software  "intensive."  Weapons  systems  are  typically 
complex  in  hardware  and  usually  employ 
special-purpose  processors  Ctequiring  extensive 
development).  Software  costs,  much  more  significant 
than  hardware  over  a  system's  life  cycle,  typically 
comprise  a  lower  percentage  of  a  weapon  system's 
overall  cost  than  with  C  systems.  Table  2.2 

differentiates  some  of  the  basic  software 

2  11 
characteristics  of  C  systems  and  weapons  systems. 

Table  2.2  may  rather  conservatively  portray 

the  percentage  of  system  cost  attributable  to 

software.  In  the  February  1985  Information 

Technology  R8D:  Critical  Trends  and  Issues  report  of 

the  U.S.  Congress'  Office  of  Technology  .Assessment, 

an  estimate  of  the  relative  cost  of  software 

1 2 

exceeded  80  percent. 

Figure  2.3  would  suggest  that  software 
costs  within  the  Department  of  Defense  double  every 
five  years,  while  computer  hardware  costs  steadily 
decline . ^  ^ 

How  does  a  commander  know  what  software 
qualities  will  support  his  individual  needs  if  he 
doesn't  know  what  technology  can,  and  will  be  able 
to  do  for  him?  This  holds  especially  true  in  areas 


SOFTWARE 
(HOURLY  RATE) 


where  automation  is  introduced  into  previously 
manual  operations. 


The  requirements  problem.  A  commander's 

2 

requirements  are  always  changing,  and  the  C  system 
must  change  to  support  these.  Some  variables 
include : 

2 

1.  The  threat.  The  gap  in  weapons  and  C 
systems  technology  enjoyed  by  the  U.S.  is 
narrowing . 

2 

2.  Geography.  C  systems  may  be  "coupled" 
with  particular  operational  settings. 
CONSTANT  WATCH  (see  glossary)  is  a  good 
example  of  this. 

3.  Doctrine.  Air  Force  doctrine  as  well  as 

"joint"  doctrine  such  as  Airland  Battle 

2 

steer  the  employment  of  C  systems. 

Doctrinal  changes  are  influenced  by 
variables  such  as  the  changing  nature  of 
the  threat  and  the  predicted  future 
battlefield  (air  and  land).  Technology 

influences  doctrine. 


4. 


Rules  of  Engagement. 


The  scenario.  Every  unified  and  specified 
command  plans  for  force  employment  in  a 


variety 

of  scenarios. 

USCENTCOM, 

for 

example , 

has  planned 

for  dozens 

of 

scenarios 

within  its 

large  Area 

of 

Responsibility.  Plans  usually  provide  only 

a  start  for  an  operation,  because  no  one 

2 

can  plan  for  all  factors.  C  systems  must 
accommodate  these  uncertainties. 

Available  systems.  As  new  systems  enter 

the  inventory  and  old  ones  are  retired  (or 

2 

still  retained)  the  C  system  supported  by 

these  systems  must  still  do  its  job. 

Operational  needs  such  as  interoperability 

further  complicate  the  need  for  complex 

2 

interfaces.  A  C  system  employed  within 
the  TACC  is  the  crux  of  the  T.^.CS. 

2 

The  commander.  A  C  system  is  employed  to 

support  the  commander,  who  is  an 

individual.  Thus,  it  is  required  to  meet 

his  specific  needs,  which  may  be  tied  to 

1 4 

all  of  the  above. 


2 

C  requirements  definition  and  system 
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acquisition  in  the  formal,  traditional  process  might 
be  executed  in  the  following  way: 

1.  The  user  develops  the  requirements  and 
hands  them  to  the  developer  (for  example,  Air  Force 
Systems  Command). 

2.  Seven  to  10  years  later,  the  technology 
supporting  the  requirement  is  obsolete  (see  "The 
Constraints,"  Chapter  IV),  user  requirements  have 
changed,  and  costs  have  escalated  to  the  point  where 
the  program  office  runs  out  of  acquisition  money. 

3.  The  resultant  system  ("thing")  is  tested 
not  against  current  or  real  user  requirements,  but 
against  contract  compliance. 

4.  User  needs  are  subordinated  to  contract 
compliance,  irrespective  of  how  well  the  contract 
meets  his  real  needs. 

5.  The  user  gets  an  obsolete  system  that  does 
not  meet  his  needs  when  fielded. 

User,  Developer,  and  Tester  Relationships 

One  of  the  study's  major  conclusions  was 
that  for  an  E.4  approach  to  be  successful,  the 
traditional  "hands-off"  relationship  among  these 
three  must  be  altered.  In  the  traditional 
acquisition  process  the  user,  after  an  end-to-end 
requirement  has  been  validated  and  passed  to  the 
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development  community,  usually  does  not  see  the 
system  until  it  has  been  developed,  tested,  and 
fielded.  In  EA  all  communities  are  involved,  to 
varying  degrees,  from  the  beginning. 

In  EA  the  "user"  is  the  operational 

commander,  the  individual  responsible  for  the 

planning  and  conduct  of  the  war.  He  is  the 

individual  for  whom  the  C  system  is  employed. 

The  Commander,  U.S.  Central  Command  Air  Forces 

CCOMUSCENTAF) ,  for  example,  is  a  user  (see 

glossary).  HQ  TAC  is  also  a  "user,"  albeit  a 

user-surrogate.  It  is  axiomatic  in  EA  that  no  one 

except  the  user  (or  user  plus  user-surrogate)  can 

2 

adequately  state  C  system  requirements,  and  this 
must  be  mainly  accomplished  by  system  use  and 
continuous  redefinition. 

The  role  of  user  and  user-surrogate  must  be 
that  of  a  partnership.  The  surrogate  must  consider 
the  needs  of  all  users  of  a  system  and  try  to  fit 
them  together  harmoniously.  The  user-surrogate  is 
responsible  for  integrating  the  evolving  systems 
into  other  systems  fielded.  The  user-surrogate 
must,  therefore,  ensure  that  one  user’s  views  are 
not  unduly  influential.^^  This  user-surrogate  re¬ 
sponsibility  will  be  seen  to  be  quite  applicable  in 
this  report's  recommended  E.^  strategy. 
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In  the  traditional  approach,  AFSC  would 
"turn  the  system  over"  to  Air  Force  Logistics 
Command  (AFLC)  upon  fielding;  AFLC  would  then  manage 
its  logistics  requirements.  In  EA,  the  development 
community  remains  a  player  throughout  the  system's 
life,  since  the  requirements  process  is  always 
ongoing.  The  general  roles  of  the  developer  in  EA 
(although  flexible)  are  to  provide  acquisition 
(non-tradit ional)  expertise,  technical  (e.g., 
architectural)  expertise,  advocacy  and  timing  of 
technology  insertion. 

There  are  no  prescribed  rules  for  this, 
and,  like  between  the  user  and  user-surrogate,  the 
role  of  user  and  developer  is  that  of  a  partnership. 

Because  under  E.'k  the  user  assumes  a  greater 
duty  in  system  testing,  the  tradition  of  the  tester 
(e.g.,  the  Air  Force  Operational  Test  and  Evaluation 
Center,  AFOTEC)  also  changes  to  that  of  a 
partnership.  Basically,  in  E.^,  the  user's  role  is 
to  test  the  system's  operational  utility;  the  tester 
retains  responsibility  for  testing  operational 
suitability.  AFOTEC's  responsibility  in  test  and 
evaluation  under  an  evolutionary  approach  might  be 
the  following: 

1.  Determining  whether  the  "core"  (or  later 
increment  to  be  tested)  is  sufficiently  reliable  and 


maintainable  to  support  operation  in  the  user's 


field  environment, 


2.  Providing  expertise  to  the  user  and 


provider  in  the  areas  of  experimental  design,  data 


acquisition,  and  data  analysis, 


3.  Supporting  the  user/developer  team  as 


required  during  test  operations  in  the  user 


environment 


4.  Conducting  operational  suitability  testing 


and  analysis  in  such  areas  as  reliability  and 


maintainability  on  suitable  test  models  (not 


necessarily  the  ’’core”) 


5.  Assessing  whether  the  selected  architecture 


has  the  capability  to  accomplish  growth,  change,  and 
i _ _  i _ _ ^ _ 1 _ 1 _  17 


insertion  of  new  technology, 


Post-AFCEA  Study  DoD  Polic 


The  DoD  did  not  mandate  and  direct  the  use 


of  EA  as  the  AFCEA  study  team  had  strongly 


recommended,  consistent  with  the  Reagan 


administration's  policy  to  "decentralize 


government."  Provisions  under  "Tailoring  and 


Flexibility"  in  DoD  Directive  5000.1,  dated 


29  March  1982,  do  support  EA  as  an  acquisition 

^  ^  ^  ^  ^  18  _ _  _ 1 _ A 


Strategy, 


Defense  Acquisition  Circular  (DAC) 


76-43,  "Acquisition  Management  and  Systems  Design 


■i 


:: 


b'-J. 


I 

I 

I 
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Principles,"  dated  28  February  1983,  though  not 

directive  in  nature,  provides  more  specific  guidance 

and  direction  in  EA  to  the  service.  Two  sections, 

2 

"Acquisition  Strategy"  and  "Command  and  Control  (C  ) 
Systems,"  are  distinctly  relevant  and  have  been 
extracted  and  included  as  appendix  D. 

JLC  policy  guidelines.  The  Defense  Systems 
Management  College  (DSMC)  has  recently  drafted 
guidelines  on  EA  to  be  signed  by  the  JLC,  the  Joint 
Logistics  Commanders: 


Richard  H.  Thompson 
General ,  USA 
Commander 

US  Army  Materiel  Command 

James  P.  Mullins 
General,  US.AF 
Commander 

.Air  Force  Logistics  Command 

Lawrence  A.  Skantze 
General ,  US.AF 
Commander 

.Air  Force  Systems  Command 

T.  J.  Hughes 

Vice  Admiral,  USN 

Deputy  Chief  of  Naval  Operations 

(Logistics) 


The  basic  purpose  of  these  guidelines,  currently  in 
coordination,  is  to  furnish  guidance  and,  if 
necessary ,  assistance  to  subordinate  commanders  "in 
negotiating  any  special  arrangements  which  might  be 
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required  to  successfully  implement  evolutionary 
19 

acquisition."  This  phraseology  assumes  special 
meaning  when  it  is  delivered  from  the  four-star 
general  level. 

EA  will  not  be  mandated.  It  is  a  viable 
2 

strategy  in  C  system  acquisition  and  DoD  has  left 
the  implementation  in  the  hands  of  the  military 
services . 


EA,  the  Air  Force,  and  1985 
The  AFMAG  Study 

In  1984,  under  the  auspices  of  the  Air 
Force  Inspector  General,  a  65-person  Air  Force 
Management  Analysis  Group  (AFMAG)  undertook  a 
three-month,  .'\ir  Force-wide  study  of  data  systems 
management  and  manpower  impacts.  The  team  collected 
and  analyzed  data,  identified  numerous  specific 
problem  areas  and  proposed  solutions.  This 
dociiment  supports  EA  and,  specifically,  prototyping 

as  a  means  to  identify  core  system  reqtairements .  The 

2  0 

AFMAG  report  gets  to  the  point. 

Air  Force  Information  Systems  Architecture 

The  .4FMAG  report,  per  se,  did  not  cause 
Headquarters,  U.S.  Air  Force  (HQ  USAF)  to  develop 
and  publish  the  Air  Force  Information  Systems 
Architecture  (AFISA)  Volume  I --Overview;  the 


document  was  under  development  during  the  AFMAG 
study.  The  senior  AFMAG  panel  chief  was  in  fact 
Brig  Gen  Denis  Brown,  the  Deputy  Assistant  Chief  of 
Staff  for  Information  Systems,  HQ  USAF.  The  AFMAG 
study's  findings,  however,  provide  obvious  support 
to  Volume  I. 

Referencing  the  DSB  Task  Force  study  and 
the  AFCEA  report,  the  AFISA  Overview  states: 


The  evolutionary  acquisition  approach  was 
originally  proposed  to  overcome  difficulties 
with  development  of  command  and  control  systems 
.  .  .  .  It  is  equally  applicable  to  complex 

systems  supporting  other  users  and  will  be 
adopted  as  the  preferred  strategy  for 
acquisition  of  all  major  Air  Force  information 
systems . 


Volume  I  is  the  first  of  a  family  of 
documents  that  will  provide  guidance  for  the  design, 
development,  acquisition  and  implementation  of 
information  systems,  supporting  the  objectives  shown 
in  Table  2.3.^^ 

The  message  of  the  AFISA,  signed  by  Lt  Gen 
Robert  H.  Reed,  Assistant  Vice  Chief  of  Staff,  is 
clear; 


All  information  systems  which  have  a 
requirement  to  interface  or  interoperate 
with  other  information  systems  will  be 
guided  by  this  architecture,  irrespective 
of  the  acquisition  methodology  or  governing 
serie^2°f  Force  regulations  actually 

used. 


TABLE  2.3 


OBJECTIVES  OF  THE  AIR  FORCE  INFORMATION 
SYSTEMS  ARCHITECTURE 


1.  Refocus  the  efforts  of  information  systems 
organizations  to  provide  better  support  to  end-users. 

2.  Enhance  information  systems  support  to  specialized 
functional  requirements  of  the  end-users  to  increase 
mission  effectiveness  or  permit  reductions  in  resource 
requirements  (funds,  people,  equipment,  etc.). 

3.  Provide  end-users  with  powerful,  flexible  integrated 
information  handling  tools  to  improve  responsiveness  and 
reduce  dependency  on  major  system  development  efforts. 

4.  Enhance  user-friendliness  of  information  systems  to 
reduce  training  requirements  associated  with  their  use  and 
application . 

5.  Provide  modem,  machine- independent  software 
engineering  tools  to  expedite  development  of  major  systems 
to  meet  user  requirements. 

6.  Achieve  increased  interoperability  through  "open 
systems"  concepts  and  compatibility  using  established 
protocols  and  standards. 

7.  Eliminate  the  existing  "air  gaps"  and  teclinical 
barriers  to  the  smooth  and  timely  flow  of  information. 

8.  Eliminate  or  replace  obsolete  and  labor-intensive 
systems  to  save  manpower  and  lower  operating  costs. 

9.  Evolve  to  fully  integrated  digital  communications 
networks  supporting  responsive  movement  of  voice,  data, 
text,  graphics  and  imagery. 

10.  Achieve  savings  by  minimizing  duplication  of  effort 
and  obtaining  more  effective  use  of  common-user  and  shared 
resources . 

11.  Achieve  increased  competition  in  the  acquisition  of 
responsive  and  reliable  system  resources. 

12.  Provide  information  privacy,  security  and  protection 
against  unauthorized  access,  use/abuse,  alteration/ 
destruction  or  denial  consistent  with  National  and  Air 
Force  directives. 
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Discussion 


.\n  apparent  sign  that  attitudes  toward  EA 

are  changing,  and  will  continue  to  change  within  the 

Air  Force  was  reflected  in  a  recent  survey  of 

2 

general/flag  officers  having  extensive  C  and 

...  .  24 

systems  acquisition  experience. 

Old  habits  don't  break  easily,  though.  Lt 

Gen  Emmett  Paige,  Jr.,  Commander,  U.S.  Army 

Information  Systems  Command,  recently  expressed  his 

concerns  about  the  "business  as  usual"  mentality  and 

the  present  inhibitors  to  Nondevelopmental  Item 

(NDI)  acquisition.  (NDI  is  an  .4rmy  initiative  to 

buy  commercial  products  and  adapt  these  products  to 

fit  military  uses--a  supposition  in  EA. ) 


The  lack  of  innovation  in  our  integrated 
logistics  support  (ILS)  concepts  preordain  that 
everything  procured  must  fit  into  and  conform  to 
standard  logistics  practices.  .  .  .  There  is 

little  reliance  on  or  use  of  vendor  test  data 
.  .  ,  .  Finally,  a  greater  emphasis  on  NDI 

often  is  mistakenly  interpreted  by  our 
government  labs  as  a  de-emphasis  and  a  loss  of 
workload  and  jobs.  ...  It's  hard  to  push  an 
NDI  project  through  the  R§D  community.  It's 
like  tiy^ng  to  stop  a  train  going  downhill 


EA  has  been  neglected  to  date  in 
significant  part  due  to  propensity  at  levels  below 
HQ  USAF  to  apply  increasingly  stringent 
interpretation  of  policy  and  guidelines. 


Program  offices  were  found  by  the  AFCEA 

study  team  to  have  to  go  to  "extraordinary  lengths 

to  get  their  jobs  done,  because  they  have  to 

'negotiate  truces'  with  each  of  the  various 

functional  groups  outside  the  program  office.  . 

.  Subterfuge  has  achieved  some  success  in 

implementing  evolutionary  strategies.  This  is 

accomplished  mainly  by  "spoofing  the  system;"  that 

is,  establishing  firm,  specific  requirements  for  the 

2 

entire  life  of  a  C  system  and  "throwing  out" 

remaining  increments  (and  starting  over)  as  each  new 

2  7 

increment  is  fielded. 

It  is  unlikely  that  the  Air  Force  will 

mandate  E.'V  until  it  has  accumulated  at  least  a  few 

achievements  in  its  database. 

The  beginning  of  "innovation  and  common 

2 

sense,"  to  use  the  DAC  76-43  phrase,  in  C  systems 
acquisition  is  rooted  in  the  AFISA.  The  guidance  is 
there  for  commanders  to  use. 
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CHAPTER  III 


THE  COMPUTER- ASSISTED  FORCE 
MANAGEMENT  SYSTEM  (CAFMS;) 

Once  the  conflict  settles  down  to  a  steady  grind 
of  mutual  destruction,  it  is  possible  to  get  a 
fix  on  many  of  the  interactions.  More  precise 
planning  is  then  possible.  Before  that  occurs, 
key  factors  are  largely  unknown. 

--James  Dunnigan,  How  to  Make  War 

The  Computer-Assisted  Force  Management 

System  (CAFMS,  pronounced  "kaff'ehms")  is  the 

primary  automated  support  to  the  AFFOR  commander- -  in 

the  contingency  T.^CS'-in  the  exercise  of  force  level 
2 

C  ,  It  is  a  means  through  which  the  order  tasking 

subordinate  elements  (e.g.,  the  WOCs)  is  compiled 

and  disseminated.  It  is  an  automated  assist  in  the 

monitoring  of  his  force  status  and  air  mission 

status.  It  is  one  of  the  systems  supporting  the 

functions  within  the  AN/TSQ-92  transportable 

shelters  of  the  TACC.  There  are  serious  problems 

today  with  C.AFMS  and  its  efficacy  as  a  force 

management  automated  "assist."  Unaddressed,  these 

problems  will  even  more  seriously  impact  on  an 

2 

operational  commander's  future  tactical  C 
capability.  This  chapter  examines  C.^FMS. 
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Background 


iii:5 


i 


w 


TACC  AUTO 


CAFMS  was  born  out  of  the  demise  of  a 

program,  Tactical  Air  Control  Center  Automation  (or 

TACC  AUTO)  which,  after  some  12  years  and  the 

expenditure  of  ^80  million,  was  terminated  "with 

prejudice"  by  Congress.  TACC  AUTO  was,  in  fact,  one 

of  the  programs  examined  by  the  AFCEA  study  team. 

It  is  one  of  the  best  cases  of  the  utter  failure  of 

a  traditional  acquisition  process  to  field  an 
2 

effective  C  system.  The  AFCEA  study  cited: 


The  absence  of  a  strong  user  role 
throughout  the  program  and  the  lack  of 
flexibility  to  adapt  to  changing  requirements 
were  key  factors  in  causing  the  program  to  fail. 
Difficulty  in  automating  many  functions,  which 
under  the  traditional  acquisition  approach 
followed  had  to  be  done  in  one  development 
cycle,  resulted  in  prolonged  delays  and  cost 
growth. 


The  beginning  of  the  T.\CC  AUTO  program  was 

a  Required  Operational  Capability  (ROC)  statement, 

dated  24  May  1967,  that  identified  the  following 

2 

requirements  of  an  automated  C  system: 

1.  Increase  capacity  and  accuracy  in  the 
display  of  the  air  situation  and  mission  progress 
data. 

2.  Maintain  status  of  forces  and  bases. 
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3.  Decrease  the  time  used  in  the  routine  and 
clerical  tasks  associated  with  mission  planning. 

4.  Decrease  the  time  required  for  preparation 
and  transmission  of  the  frag  (the  air  tasking) 
order. 

5.  .Automatically  generate  and  disseminate 

^  2 
status  and  summary  reports. 

Providing  this  capability  to  the  air 
component  commander  couldn't  be  done  in  13  years  for 
the  basic  reasons  stated  in  the  .AFCEA  study.  The 
elementary  requirements  after  T.ACC  .AUTO  was  killed 
however,  remained  similar  to  those  listed  in  1967: 
improve  the  timeliness,  accuracy,  and  completeness 
of  the  mission  planning  and  operations 
monitoring/assessraent  functions. 

CAFMS  Phase  I 

HQ  T.AC  quickly  prepared  statement  of 
requirement,  named  the  required  capability  something 
not  remotely  resembling  TACC  .AUTO  (hence,  C.AFMS)  , 
and  received  .Air  Staff  approval  to  acquire 
commercial  Automatic  Data  Processing  (ADP)  hardware 
and  software  to  field  a  "Phase  I"  operational 
capability . 

The  objectives  of  C.AFMS,  as  outlined  in 
TAG'S  June  1979  Data  .Automation  Requirement  were 
s imply : 
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1.  Construction  and  review  of  the  Air  Tasking 
Order  (ATO). 

2.  Dissemination  of  the  ATO  via  remote 
terminals,  AUTODIN,  and  teletype. 

3.  Automatic  generation  of  mission  schedules. 

4.  Updating  displays  (tabular  and  graphic). 

5.  Reports  generation. 

6.  Interfaces: 

a.  TADIL-B. 

b.  DC/SR. ^ 

Phase  I,  begun  in  1979,  established  TAC  as  the 
overall  CAFMS  Program  Manager,  with  Headquarters, 
Electronic  Systems  Division  (Air  Force  Systems 
Command)  providing  technical  assistance  in  hardware 
and  software  acquisition,  configuration  management, 

4 

engineering,  and  logistics. 

Much  of  the  code  written  for  applications 
supporting  T.ACC  AUTO  was  translated  to  CAFMS,  and 
literally  dozens  of  TACC  .'VUTO  software  support 
personnel  were  available  to  develop  C.^FMS 
applications.  The  CAFMS  project  was  established  in 
two  phases  and  began  as  an  evolutionary  effort. 

Phase  I  activities  were  aimed  at  getting 
CAFMS  into  the  hands  of  the  users:  Ninth  Air  Force 
(9th  AF) ,  Twelfth  .Air  Force  (12th  .AF)  ,  and  the 
US.AF  Tactical  .Air  Warfare  Center  (US.AFT.AWC) .  .An 


additional  system  was  delivered  at  HQ  TAG  to  support 
software  development  and  maintenance.  .'Vlthough  HQ 
TAG  acted  on  behalf  of  the  "real  users,"  there  was 
during  Phase  I  continual  input  from  the  field  into 
G.\FMS'  development.^  Phase  II  was  designed  to  allow 
ESD  to  undertake  a  series  of  enhancements /upgrades 
to  the  GAFMS  systems.  The  objective  was  to  field 
two  "fully  deployable"  systems,  one  software  support 
facility  and  one  test  facility  that  were  completely 
logistically  supportable  and  Air  Force  maintained. 
Planned  improvements  included  ruggedization  of 
equipment,  development  of  a  full  complement  of  war 
readiness  spares,  manpower  allocation,  and  other 
improvements  to  establish  a  system  baseline. 

After  all  units  were  fielded,  G.^FMS  was 
deleted  from  the  HQ  US.^F  Program  Management 
Directive  for  Tactical  .^ir  Gontrol  Systems 
Improvements.^  Since  1982,  GAFMS  has  survived  on 
end-of-year  (fiscal  year)  fall-out  funding.  Ninth 
.Air  Force  has  been  able  to  receive  some  operations 
and  maintenance  CO§M)  funding  from  USGENTGOM  for 
maintenance  of  its  G.AFMS.  The  Air  Force  .Audit  .Agency 
.Area  .Audit  Office  cited  in  1984  ,  among  other 
problems,  poor  maintenance  contractor  performance 

7 

and  ineffective  management  of  the  G.AFMS  program. 

The  GAFMS  Program  Review  Organization 
(essentially  a  committee  for  G.AFMS  matters)  was 


dissolved  during  the  summer  of  1985,  and  overall 
CAFMS  responsibility  was  assumed  by  the  Command  and 
Control  Systems  Directorate  CHQ  TAC/DOY)  along  with 
all  TACC  matters. 

The  Generic  CAFMS 

The  Hardware 

The  heart  of  CAFMS  is  a  Perkin-Elmer  model 
3230  (PE  3230)  32-bit  minicomputer.  The  Central 
Processing  Unit  (CPU)  has  access  to  4  MB  of  primary 
memory  and  320  MB  of  secondary  memory  located  in 
four  Trident  T-80  disk  units. 

At  the  operating  station  of  the  system  are 
a  Centronics  model  6600  600  LPM  printer,  one 
Perkin-Elmer  800/1600  BPI  magnetic  tape  unit,  a 
Perkin-Elmer  model  1245  local  terminal  (operator 
station) ,  and  a  Remex  6075  paper  tape  punch/reader. 

The  main  processor  is  configured  to  support 
18  local  ("dumb")  terminals  (the  Perkin-Elmer  1245) 
through  standard  two-line  communications 
multiplexers . 

CAFMS  supports  up  to  12  remote  terminals, 
which  are  located  at  the  Wing  Operations  Centers 
(WOCs),  the  Control  and  Reporting  Centers  (CRCs), 
and  the  .^ir  Support  Operations  Center  (ASOC)  (see 
appendix  E) .  The  remote  terminal  can  be  employed  as 


a  workstation  and  is  comprised  of  the  Delta  Data 
model  7586  microcomputer,  with  dual  8"  floppy  disk 
drives  and  a  dot  matrix  printer.  Connectivity  to 
the  3230  is  via  standard  tactical  or  commercial 
systems.  TSEC/KG-30  (soon  to  be  fully  upgraded  to 
TSEC/KG-84)  cryptographic  equipment,  table-top 
modems,  and  Micom  error  controllers  provide  for 
secure  transmission  between  the  host  and  remotes. 
The  current  modems  for  the  system  operate  at 
1200/2400  bps.  Host  to  remote  communications  is 
four-wire.  .4t  present  C.4FMS  cannot  be  supported  by 
tactical  high  f requency/independent  sideband 
(HF/ISB)  radio.  Early  testing  performed  by  the 
MITRE  Corporation  indicated  problems  with  the  MD 
1061  HF  modems  supporting  data  communications 
following  brief  propagation  losses.  This  is 
presently  being  studied.  C.4FMS  also  does  not  have  a 
satellite  communications  capability. 

The  Software 

C.4FMS  uses  the  Perkin-Elmer  Operating 
System  32  (OS  32),  version  6.2,  the  latest  version, 
in  current  operation.  This  operating  system  has 
been  designed  to  support  up  to  255  concurrent  users. 

The  database  management  system  (DBMS) 
supporting  C.4FMS  is  the  original  version,  a  version 
considered  by  1985  standards  to  be  incredibly  slow 


and  inefficient. 


Perkin-Elmer  is  said  to  be 


presently  beta  testing  version  8.0. 

CAFMS  software  is  written  in  COBOL 
(approximately  90  percent),  F0RTR.4N  (about  eight 
percent),  and  Assembler  (two  percent).  Compilers 
used  to  support  these  applications  are  very  early 
versions.  Funding  has  never  been  made  available  to 
upgrade  this  software,  and  this  has  contributed 
greatly  to  poor  system  response  times  experienced  by 
system  users  (especially  the  remote  users). 

Specific  System  Capabilities 

The  PE  3230  system  has  been  designed  to 
provide  the  user  these  basic  capabilities: 

1.  A  start-up  function  that  initializes  the 
system,  sets  up  specific  duty  authorizations, 
assigns  message  addressee  designators  and  locations, 
and  "pre-stores”  certain  data  base  records. 

2.  An  orderly  shutdown  function  that  completes 
the  processing  of  any  outgoing  messages  and  allows 
the  operator  to  remove  the  system  and  database  disk 
packs  prior  to  erasing  the  remaining  computer  memory 
and  disk  packs. 

3.  A  message  transmission  capability  that 
provides  for  off-line  transmission  and  receipt  of 


paper  tape  (the  upgrade  to  magnetic  cassette  media 
is  in  progress)  to  units  not  equipped  with  a  remote 
terminal.  Outgoing  messages  may  be  formatted  in 
either  JANAP  128  or  JINTACCS  message  formats. 

4.  ATO  generation.  CAFMS  software  has  been 
designed  to  allow  up  to  26  separate  ATOs  to  be 
constructed/maintained  concurrently.  The  user  may 
review  the  ATO  in  either  standard  ATO  format  or  in 
JINTACCS.  Once  the  message  is  completed,  units  are 
notified  and  they  may  access  the  ATO  from  the  data¬ 
base. 

5.  Mission  and  force  status  monitoring.  CAFMS 

can  maintain  force  status  information  (e.g., 

aircraft  status,  airfield  status,  munitions  status) 

and  display  this  information,  once  input  by  the 

user,  on  one  of  several  "tactical  displays." 

Mission  schedules  may  be  updated  from  either  local 

or  remote  terminals  and  displayed  in  a  variety  of 
8 

ways . 

The  Software  Support  Facility 

The  1912th  Information  Systems  Support 


Group  C1912th  ISSG)  is  C.^FMS '  Software  Support 
Facility  (SSF) .  The  1912th,  among  other  missions, 
provides  software  development  and  maintenance 


services  for  the  TAGS.  At  present  there  are  35 
officer  and  enlisted  personnel  assigned  to  CAFMS 
support  functions,  which  translates  to  35  man-years 
per  year  of  labor.  As  of  October,  1985  ,  135 

applications  programs,  written  in  COBOL,  reside  on 
software  version  4.0.  Not  including  system 
software,  this  accounts  for  approximately  350 
thousand  lines  of  code.  Additionally,  there  are  125 
Assembler  programs  (approximately  50  lines  each)  and 
15  FORTRAN  programs  (approximately  2000  lines  each). 
Ninety-six  percent  of  usable  memory  is  consumed 
before  the  user  ever  logs  on. 


The  Contractor 


All  hardware  logistics  support  and 
configuration  management  of  CAFMS  hardware  has  been 
contracted  to  IMR  Systems  Corporation.  The  cost  of 


fiscal  year  (FY)  85  planned  and  remedial  maintenance 
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services  was  $683,802.  FY  86  maintenance  costs  are 
expected  to  exceed  $700,000.  Air  Force  Perkin-Elmer 
trained  maintenance  personnel  assist  IMR  technicians 
at  the  field  sites.  IMR  technicians  routinely 
support  CAFMS  on  deployments,  both  in  the  CONUS  and 
overseas.  Deployment  options  provided  in  the 
contract,  to  include  deployments  to  hostile  overseas 
areas,  are  to  be  "negotiated  prior  to  each 


deployment . 
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The  Field  Sites 


In  addition  to  the  SSF,  CAFMS  is  fielded  at 
the  12th  AF,  Bergstrom  AFB,  Texas  (602nd  TACCS) ;  the 
9th  AF,  Shaw  AFB,  South  Carolina  (507th  TACCS);  and 
the  USAFTAWC  (727th  TCS(T))  at  Hurlburt  Field, 
Florida.  The  hardware  configuration  is  not  standard 
among  the  three  field  sites.  IMR  Systems 
Corporation  maintains  and  spares  all  CAFMS  equipment 
at  the  sites.  During  spring  1  98  5  IMR,  at  the 
request  of  the  CAFMS  Program  Review  Organization 
(PRO),  developed  a  list  of  60-day  contingency  spares 
($670,000)  required  for  the  CAFMS  sites. This  was 
one  of  the  PRO'S  initiatives  to  "baseline"  C.\FMS. 
Funding  was  never  allocated  for  this  and  all  CAFMS 
sites  remain  contractor- dependent  for  most  logistics 
matters.  At  present  the  12th  .\F's  C.^FMS  serves  as 
the  contingency  spares  supply  for  the  9th  AF,  and 
vice  versa. 

A  7  March  1985  PRO  Assessment  Briefing 
revealed  that  HQ  USAF  had  "validated"  but  not  funded 
computer  maintenance  (AFSC  305X4)  personnel  for 
CAFMS  maintenance.  All  sites  have  taken  personnel 
from  authorized  billets  to  work  with  IMR. 
Technically,  however.  Air  Force  personnel  are  not 
allowed  to  perform  system  maintenance. 


There  is  no  way  that  credible  reliability 
statistics  can  be  gathered.  Until  late  1984  there 
were  no  command  level  maintenance  reporting 
requirements  levied  on  CAFMS.  There  has  been 
limited  job  control  reporting  at  the  site  locations, 
and  maintenance  personnel  candidly  report  that 
procedures  are  seldom  followed.  Lack  of  system 
visibility  and  contracted  logistics  support  motivate 
few  people  to  become  concerned  when  equipment 
breaks.  System  reliability  figures  on  CAFMS,  while 
deployed  on  exercises,  are  conflicting. 

Training  of  CAFMS  operations  personnel  at 
the  sites  is  nonstandard  and  has  been  judged 
inadequate  by  TAG.  One  of  the  basic  problems  is  the 
almost  extreme  user  "unfriendliness"  of  the  system, 
according  to  C.^FMS  operators.  .A.11  sites  conduct 
in-station  training  but  rely  heavily  on  augmentation 
during  exercises.  Operations  personnel  Coften 
clerk-typists)  who  have  been  fortunate  enough  to 
learn  CAFMS  to  a  subjective  level  of  proficiency 
find  themselves  on  what  a  few  consider  to  be  "more 
than  their  share"  of  exercises. 

Bergstrom  AFB.  The  CjXFMS  belonging  to  12th 
AF  is  located  in  an  S-560  "3:2"  standard  shelter 
that  was  obtained  from  salvage  when  C.\FMS  was 
introduced.  The  shelter  leaks  when  it  rains,  so 


602nd  TACCS  personnel  cover  it  with  a  tarp. 
Humidity  in  the  van  and  shelter  leakage  have  caused 
corrosion  on  the  Trident  disk  drives. 

Hurlburt  Field.  C.\FMS  at  Hurlburt  Field  is 
owned  by  the  727th  TCS(T)  and  is  used  primarily  to 
support  exercises  of  the  USAFTAWC  Air-Ground 
Operations  School  (AGOS)  and  Blue  Flag,  a  TAG 
readiness  training  program.  CAFMS  remains  in  an 
S-560,  3:2  shelter  located  adjacent  to  the  Blue  Flag 
building.  Terminals  are  situated  in  the  AGOS  and 
Blue  Flag  buildings  to  support  particular  scenarios. 
AGOS  utilizes  CAFMS  six  times  per  year;  Blue  Flag 
utilizes  C.'XFMS  quarterly,  but  only  one  exercise  per 
year  supports  a  contingency  TAGS  scenario 
(USCENTCOM) .  Such  major  exercises  as  JCS  Exercise 
BOLD  E.^GLE  85  have  been  supported  by  the  727th. 

The  shelter  at  Hurlburt  leaks,  too,  and 
humidity  is  a  problem,  but  727th  personnel  have 
taken  creative  maintenance  measures: 

1.  Caulking  the  leaks  Cfive  tubes  of 

caulking) . 

2.  Installing  dehumidifiers  in  the  van. 

3.  Painting  the  roof  white  to  reflect  the  sun. 

Shaw  .\FB.  The  507th  TACCS  is  considerably 
better  off  than  its  peers.  C.^FMS  at  Shaw  is  housed 
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in  an  8’x  8’x  20’  shelter.  This  shelter,  configured 
by  the  MITRE  Corporation  as  a  "prototype"  shelter, 
was  delivered  in  1983.  Unlike  the  other  systems, 
9th  AF  has  a  backup  (though  not  an  on-line  backup) 
Perkin-Elmer  3230.  The  big  problem  with  this  van  is 
that  it  weighs  18,500  lbs  and  cannot  be  tactically 
airlifted.  The  attached  mobilizers  (wheels)  cannot 
safely  support  towed  speeds  exceeding  5  mph  on 
smooth  surfaces,  and  towing  requires  an  aircraft  tug 


(non-standard  TAGS  equipment). 


Thus ,  normal 


surface  transportation  for  C.^FMS  is  by  40'  flatbed 
trailer. 


A  Typical  Configuration 

Figure  3.1  depicts  a  typical  configuration 
of  systems  residing  at  the  T.'^CC.^^  In  this  case  it 
is  a  9th  AF  TACC  (12th  AF  does  not  have  a  Message 
Processing  Center,  MPC) .  One  develops  a  feeling  for 
CAFMS'  vulnerability  after  tracing  a  few  lines  from 
the  WOCs ,  the  CRCs,  etc.,  to  the  18,500  lb 
".‘Achilles'  heel,"  the  single  point  of  system 


failure . 


The  T.ACC  is  supported  by  a  miscellany  of 


manual  and  automated  systems  developed  under 
independent  programs.  .Appendix  E  describes  various 
elements  represented  in  Figure  3.1. 
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Air  Tasking  Order  information  can  be  passed 
to  only  12  remote  terminals.  Intelligence  and 
operations  systems  cannot  share  information  for 
constructing  or  executing  the  ATO  nor  can  the  latest 
intelligence  information  be  readily  accessed  by  the 
Wings,  the  CRCs ,  and  the  ASOC.  CAFMS  information  is 
received  and  updated  by  each  Wing,  CRC,  and  ASOC 
through  a  single  terminal,  creating  a  "choke  point" 
for  information  at  these  levels.  Units  do  not 
presently  have  any  internal  automated  network  to 
rapidly  collect  information  required  at  the  AFFOR 
headquarters,  and  tasking,  intelligence,  logistics, 
and  flight  planning  information  cannot  be  shared  at 
the  unit  level. 

There  are  no  means,  other  than  voice 
(radio)  or  manual  (hand  carry) ,  to  disseminate  the 
.A.TO  and  its  changes  to  the  ABCCC  (see  glossary). 
The  .^BCCC,  operated  by  the  7th  .Airborne  Command  and 
Control  Squadron  (7th  .ACCS),  Keesler  .AFB,  MS, 
functions  as  an  alternate  T.ACC  and  alternate/backup 
ASOC.  There  are  no  means  to  transmit  digital  data 
via  HF/ISB  radio  or  SHF  S.ATCOM  directly  from  C.AFMS. 

The  Band-.Aid  to  C.AFMS 

.As  an  effort  to  improve  C.AFMS  system 
performance,  maintainability,  and  reliability,  HQ 


TAG,  using  0§M  funding,  has  recently  undertaken  a 
project  to: 

1.  Replace  CAFMS  local  and  remote  terminals 
with  TEMPEST  certified  Zenith  Z-151  microcomputers. 

2.  Replace  the  non-TEMPEST  Okidata  printers 
with  TEMPEST  certified  printers. 

3.  .Acquire  new  disk  drives  (both  fixed  and 
removable)  and  disk  controllers  to  eliminate  the 
present  input/output  bottleneck  and  to  increase 
system  response  time. 

4.  Replace  the  proprietary  hardware  Ci*e., 

bootloaders)  built  and  installed  by  the  initial 
14 

contractor. 

5.  Replace  the  outdated  software  presently 
used  with  current  versions. 

6.  Acquire  a  software  maintenance  package  to 
receive  future  software  editions. 

The  plan  is  to  acquire  hardware  and 
software  to  be  used  by  the  C.4FMS  SSF  to  test, 
modify,  and  develop  applications  compatible  with 
this  new  hardware  and  software.  A  decision  will  be 
made  at  a  later  date  to  acquire  this  equipment  for 
the  three  field  locations.  It  is  anticipated  that 
C.4FMS  version  5.0  will  be  designed  to  operate  on  the 
new  equipment,  but  it  is  unlikely  that  the  new 
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hardware  and  software  will  be  installed  prior  to 
1987.  Not  including  manpower  costs  associated  with 
the  SSF,  the  total  cost  is  estimated  to  exceed  $1.5 
million. 


Summary 


The  evolution  of  CAFMS  came  to  a  grinding 

halt  in  1982  when  the  program  was  deleted  from  the 

the  PMD.  Lack  of  management  visibility  on 

automation  within  the  TACC,  lack  of  user  involvement 

in  the  CAFMS  program  since  1982,  and  the  perception 

of  CAFMS'  usefulness  are  a  few  probable  causes  of 

its  present  status.  It  is  doubtful  that  either  the 

9th  or  the  12th  Air  Force  commander  would  seriously 

consider  the  deployment  of  CAFMS  on  anything  short 

of  a  major  conflict.  The  scarce  availability  of 

airlift  would  more  than  likely  relegate  CAFMS  to  the 

follow-on  of  follow-on  forces.  C.^FMS  has  never  been 

exercised  during  a  "real-world"  operation,  anyway, 

and  the  current  perception  of  its  reliability  is 

that  it  could  take  days  (and  it  sometimes  has  taken 

days)  to  become  operational.^^  The  requirement  for 

rapid  reaction  and  flexibility  in  support  of 

Operation  Urgent  Fury  in  Grenada  ("Summary,"  Chapter 

VI)  could  not  have  been  met  using  the  present  force 
2 

level  C  system. 


mm 


Air  Force  Major  General  Prather,  at  the 
time  he  was  serving  as  Director  of  Command  and 
Control,  and  Telecommunications  at  HQ  USAF,  stated; 
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Ov€^  the  years,  immediate  availability  of 
.  .  .  C  I  services  has  been  the  expected  norm. 
Experience  has  shown  that  the  real  time,  real 
world  crisis  is  a  totally  different  animal. 

Typically  we  face  a  situation  that  is  of 
national  importance,  time  critical  and  totally 
without  preplanning.  The  need  for  equipment 
is  immediate,  and  decision  makers  must  make  do 
with  what  is  available  while  real  needs- and  C^I 
equipment  availability  are  identified."^ 


From  the  operational  side.  General 
Kingston,  Commander  in  Chief  of  USCENTCOM  last  year 
declared: 


I  am  concerned  that  our  old  equipment  just  won't 
stand  the  test.  USCENTCOM's  goal  is  a 
responsive,  interoperable  system  or  network  o£ 
systems  that  works  from  the  ground  up.  New 
developments  must  be  able  to  contribute  to  the 
overall jffliss ion  of  commanding  and  controlling  my 
forces . 


2 

The  concept  of  employment  of  force  level  C 
has  already  begun  to  change.  The  next  chapter 
addresses  the  status  of  TACS  systems  planning  and 
its  impact  on  the  operational  community. 

With  no  funded  programs  to  replace  CAFMS, 
the  user  does  not  have  a  system  that  can  adequately 
meet  his  present  or  changing  needs.  That  is  the 
bottom  line  assessment  for  tactical  force  level  C  . 
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CHAPTER  IV 


PLANNING  FOR  THE  FUTURE 

We  need  to  think  war,  develop  wartime 
systems  and  then  adapt  them  to  peacetime  use; 
and  not  develop  peacetime  systems  and  then  try 
in  vain  to  make  them  wartime  capable,  as  we 
often  have  done  in  the  past. 

--Maj  Gen  John  T.  Stihl 

The  Master  Plan 
2 

The  TAF  C  Improvements  Developers '  Guide 

is  the  document  most  action  officers  at  the 

headquarters  use  to  try  to  make  sense  of  how  their 

particular  programs  fit  into  the  overall  development 
2 

of  TAF  C  capabilities.  The  purpose  of  this  guide 
is  to  incorporate  two  documents,  the  Tactical  Air 
Forces  Integrated  Information  System  (TAFIIS)  Master 
Plan  and  the  Developers*  Guide,  into  one  somewhat 
concise  document.  The  1984  edition  of  the 
Developers '  Guide  contained  49  separate  programs.^ 
The  .August  1985  Tactical  .^ir  Forces  Interoperability 
Group  (T.'VFIG)  Smart  Book,  sort  of  TAFIG's  version  of 
the  Developers'  Guide,  summarizes  75  programs 
currently  being  staffed. 

There  are  numerous  programs,  in  various 
stages,  designed  to  improve  the  AFFOR  commander's 
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command  and  control  capabilities.  The  Modular 
Control  Equipment  CAN/TYQ-23)  Project  (MCEj ,  for 
example,  is  planned  to  replace  the  C  operations 
centers  (AN/TSQ-91,  AN/TSQ-61)  of  the  CRC,  and  the 
Message  Processing  Center.  MCE  is  a  $2.3  billion 
undertaking.  This  program  and  several  others,  such 
as  the  Ground  Attack  Control  Center  Csee  glossary) , 
are  either  included  in  the  HQ  USAF  Program 
Management  Directive  (PMD)  for  TACS  Improvements  or 
have  their  own  Program  Management  Directives.  The 
PMD  is  the  implementing  document  for  a  program  to 
enter  the  "Demonstration  and  Validation  Phase"  in 
the  traditional  acquisition  process. 

The  Road  Map 

One  document,  the  T.^FIIS  Master  Plan, 

attempts  to  depict  the  relationships  and 

interrelationships  among  the  plethora  of  programs. 

It  presents  these  in  a  manner  intended  to  afford  the 

staff  officer  a  single  multi-volume  document 

containing  the  design  for  overall  system  growth,  a 

framework  for  program  development,  a  basis  for 

acquisition  inputs,  a  set  of  "road  maps"  depicting 

timetables  and  milestones  of  the  various  programs, 

2 

and  other  nice  to  have  information. 

The  basic  problem  with  the  Master  Plan  has 
been  its  size,  classification  Cmost  volumes  are 


.V 

■W, 


. 


* 

it 


classified  Secret) ,  and  complexity.  Staff  officers 
typically  do  not  have  the  time,  the  patience,  or  the 
background  knowledge  to  wade  through  the  program 
"road  maps"  and  descriptions  contained  in  the  Master 
Plan  (which  must  be  stored  in  a  safe)  to  make  sense 
of  their  particular  program(s).  The  document  has 
remained  largely  unseen,  and  particularly  unread,  at 
levels  that  really  need  the  information  it  contains. 

The  Revised  Master  Plan 

Beginning  in  the  summer  of  1985,  the  TAP IIS 
Master  Plan  underwent  a  major  revision,  the  basic 
purpose  of  which  was  to  produce  a  more  practical 
document  ("user  friendliness"  is  not  just  a  computer 
term).  When  it  is  completed  (TechPlan,  Inc.  has 
been  contracted  to  rewrite  the  plan)  in  January 
1986,  it  should  be  a  much  smaller,  better  organized 
and  synthesized  document.  A  major  effort  has  been 
made  to  make  the  plan  understandable  while 
supporting  these  goals: 

2 

1.  Provide  a  framework  for  C  systems 
development . 

2.  Provide  an  approach  for  reduced  duplication 
in  R3D  and  procurement. 
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3.  Support  the  TAF  C  Improvements  Plan  and 

relate  to  several  other  documents,  such  as 
21st  Century  TAGS. 

It  is  dubious  that,  at  least  in  the  near 
future,  the  Master  Plan  will  be  more  than  a  basic 
reference  guide,  A  paper  study  alone  will  not 
satisfy  TAC's  architectural  requirements  (see  "The 
Transition  to  the  Future,"  this  chapter). 

The  Future  TAGS 

.Analyses  such  as  those  presented  in  Airland 

Battle  2000,  Air  Force  2000,  21st  Century  TAGS,  and 

the  Marine  Corps  Science  Technology  Objective  (STO) 

254  depict  a  future  surface/air  battlefield  that  is 

highly  dynamic,  deep,  and  very  destructive.  The 

"worst  case"  is  usually  presented  in  such  reports, 

the  worst  case  being  a  conflict  scenario  involving 

substantial  Soviet  and  U.S,  forces. 

The  time  allowed  the  operational  commander 

to  command  the  air  battle  is  compressed  dramatically 

2 

in  such  a  scenario.  Future  C  will  be  characterized 
by  extremely  high  data  rates  and  processing  speeds, 
decision  support  through  .^I  and  knowledge-based 
systems,  networks  designed  for  flexibility  and 
survivability,  and  joint/combined  operations  under 


stress  (electronic  combat,  nuclear,  biological,  and 
chemical  warfare). 

21st  Century  Tactical  Command  and  Control 
Architecture.  A  large  team  comprised  of  50  Air 
Force  and  industry  experts  recently  concluded  a 
year-long  study  sponsored  by  HQ  USAF  and  the  Defense 
Advanced  Research  Projects  Agency  (DARPA) .  The 
basic  aim  of  the  study,  2l5t  Century  Tactical 
Command  and  Control  Architecture,  was  to  address 
high  level  user  requirements  and  describe  a  general 
future  TACS  architectural  framework  within  which 
those  requirements  can  be  realized.  The  study 

received  broad  oversight  from  the  HQ  USAF  Tactical 

2  3 

C  Steering  Group. 

The  study  breaks  the  future  T.^CS  into  three 
functional  subarchitectures:  Air  Surveillance 

Management  and  Control;  Surface  Surveillance 
Management  and  Control,  and  Force  Planning.  The 
general  requireiients ,  considered  "dominant  concerns" 

4 

for  a  future  architecture,  are  listed  in  Table  4.1. 
Dispersal  of  elements,  replication  of  databases 
supporting  those  elements,  and  distribution  of 
functions  supporting  the  Force  Planning  (FP)  mission 
comprise  the  basic  FP  architecture  in  this  21st 
Century  TACS.^  Within  this  architecture  operations 


TABLE  4.1 


GENERAL  REQUIREMENTS  OF  THE  FUTURE  TAGS 


OPERABILITY  INHERENT  TRAINING  CAPABILITY 


-24  HOUR  OPERATIONS 
CAVAIUBILITY) 

-USER  FRIENDLY 
-DEPLOYABLE 
-FLEXIBLE/ ADAPTABLE 
GROWTH 

-MINIMUM  ATTENDANCE 
(LOW  MANPOWER) 

SURVIVABILITY 

-MOBILITY 
-NBC  HARDENING 
-DISTRIBUTED/DISPERSED 
OPERATION 

-CAMOUFLAGE  DECEPTION 

SUP PORTABILITY 

-MAINTAINABILITY 

-SELF-SUSTAINING 

-COMMONALITY 

INTEROPERABILITY/ 

COMPATIBILITY 


-SIMULATION/LIVE 
-OPERATIONS /MA INTENANCE 
- INTERNAT I ONAL/ EXTERNAL 
-INDIVIDUAL  TEAMS 

AFFORDABILITY 

-BACKWARD  COMPATIBLE 

-MODULAR 

-SIMPLE 

-RELIABLE 

TRANSPORTABILITY 

-MODULAR 
-SMALL  SIZE 
-LIGHTWEIGHT 

ENVIRONMENTAL  ADAPTABILITY 

-ALL  WEATHER 
-DAY /NIGHT 
-TERRAIN 
-CLIMATOLOGY 


-COMMUNICATIONS 
(SECURE,  AJ) 
-DATA  BASES 
-JOINT  AND  ALLIED 
-OLD  AND  NEW 


and  intelligence  functions  are  highly  inter¬ 
dependent. 


At  present  the  document  is  under 
consideration  at  HQ  USAF  to  be  the  basic  concept 
document  for  the  future  TAGS  architecture. 

What*s  Going  on  in  1985 
The  Constraints 

HQ  TAG  is  presently  working  on  a 
technical  architecture  for  the  TAGS.  The  approach 
has  been  to  identify  the  current  system  capability 
(e.g.,  equipment,  connectivity)  first,  fit  the 
currently  funded  programs  (e.g.,  TRI-TAG,  MCE)  into 
this,  and  then  identify  the  shortfalls.^ 

One  immediate  constraint  in  planning  an 
architecture  that  resembles  the  one  articulated  in 
21st  Century  Tactical  Command  and  Control 
.Architecture  is  the  fielding  of  Joint  Tactical 
Communications  (TRI-T.AC)  program  equipment  (see 
glossary).  The  overall  T.ACS  architecture  will  be 
heavily  influenced  by  the  TRI-T.AC  program  (which 
began  in  1969)  for  a  number  of  years,  with  its 
non- state-of-the-art  equipment  and  inflexibility  in 
accommodating  changing  requirements.  The  problems 
of  providing  overall  network  survivability  have 
actually  grown  worse  with  TRI-TAC.  Since  the  Army 


opted  out  of  the  program,  lowered  equipment 
production  has  caused  prices  to  escalate.  The  Air 
Force  cannot  purchase  the  amount  of  equipment  that 
it  had  originally  planned  to,  so  operations  planning 
will  be  even  more  impacted  from  reduced  connectivity 
and  other  user  services. 

The  Frustration 

Force  management  will  show  up  as  one 
obvious  shortfall  in  TAGS  architecture  development. 
It  is  a  shortfall  today.  The  concept  of  TACC 
employment  is  already  changing  to  meet  the 
operational  missions  of  the  Numbered  Air  Force 
commanders.  Flexibility,  reliability,  survivabili¬ 
ty,  modularity,  etc.,  are  not  concepts  that  TAG  can 
wait  until  1995  to  begin  incorporating  into  its 
systems . 

The  expected  scarcity  of  airlift  during  a 
Southwest  Asia  operation  has  already  motivated  the 
planning  for  reduced  airlift  reliance  in  TAGG 
deployment.  Mission  Gapabilities  Statements 
(MISG.'^Ps)  ,  dated  11  September  1985  ,  forwarded  to  HQ 
T.'VG  from  9th  AF  reflect  a  different  method  of  taking 
the  TAGG  to  war.  Ninth  Air  Force  has  reduced  its 
airlift  requirements  by  over  one-third  (down  from  33 
G-141B  equivalent  aircraft  loads  to  20)  and  has 
adopted  an  echeloned  employment  concept.  The  total 


9th  AF  TACC  package,  including  automated  intelli¬ 
gence  support  CLENSCE),  has  been  divided  into  three 


packages.  The  first  is  a  quick  response  initial 
package  and  does  not  include  CAFMS.  The  second  is 
designed  to  bring  the  TACC  to  full  operational 
capability.  The  third  package  is  planned  to  arrive 
by  sea  and  provide  full  road  mobility  and  increased 

7 

communications.  The  second  package  [the  T.^CC 
follow-on)  calls  for  a  25,000  lb  all-terrain 
forklift,  or  20,000  lb  capable  crane  and  40' 
flatbed,  to  position  CAFMS.® 

Users  in  the  "requirements  business."  The 
method  that  9th  AF  has  used  to  develop  an  initial 
TACC  capability  is  a  result,  clearly,  of  Cl)  their 
experience  with  CAFMS  and  a  still  predominantly 
manual  TACC,  (2)  the  18-month  lag  time  between 
software  application  identification  and  completion 
and  the  sense  of  futility  experienced  in  making 
C.4,FMS  operational,  (3)  operational  requirements 
CAFMS  cannot  start  to  fulfill,  and  C4)  increasing 
computer  literacy  among  users.  What  9th  AF  has  done 
is  taken  their  own  initiatives.  Using  an  assortment 
(a  "kluge")  of  microcomputers  (e.g.,  CROMEMCO  CS-2s, 
Zenith  Z-150s)  and  microcomputer  software,  a  small 
group  of  PC  afficionados  has  built  a  multiuser 
system  capable  of  building  a  limited- sortie  ATO  and 


presenting  force  status  information  in  user-friendly 
formats.  They  have,  as  they  say  at  HQ  TAC,  placed 
themselves  in  "the  requirements  business.” 

Such  behavior  is  not  likely  to  be  met  with 
continued  patience  among  those  in  senior  staff 
positions  at  TAC,  and  for  good  reason.  T.A.C  i^  in 

9 

the  requirements  business. 

The  9th  AF  is  not  alone  in  its  frustration, 
however.  Staff  officers  at  the  1st  Marine 
Amphibious  Force  (I  MAF),  Camp  Pendleton, 
California,  have  resorted  to  similar  measures.  In  a 
letter  from  the  Commanding  General,  I  MAF  to  the 
Commandant  of  the  Marine  Corps: 


What  has  changed  rapidly  is  th&  environment  in 
which  this  function  [i.e.,  C^]  must  be 

accomplished.  The  demand  placed  on  C^  systems 
by  the  modern  battlefield  greatly  complicate 
what  has  neA^er  been  an  easy  task.  .  .  .  These 

increased  C^  demands  bring  new  requirements  for 
both  procedures  and  supporting  systems  feinphasis 
added  ] .  The  grease  pencils,  map  displays ^  hand 
delivered  messages  and  face-to-face  C'^ 
coordination  measures  utilized^within  the  Marine 
Corps  will  no  longer  suffice. 


The  Transition  to  the  Future 

.\s  the  technical  architecture  for  the 
post-1985  TACS  is  developed,  TAC  must  work  now  to 
meet  user  requirements  in  the  near  term, 
validate/revalidate  existing  functional  requirements 
within  the  TACC,  articulate  the  technical  and 
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functional  requirements  for  force  management,  and 

2 

field  a  force  level  C  system  that  can  evolve  within 
an  architecture  as  requirements  and  technology 
change.  That  is  no  small  job. 

Air  Force  Information  Systems  Architecture, 
Volume  II  (draft)  provides  the  following  direction 
in  the  transition  from  the  existing  situation  to 
targeted  capabilities; 

This  strategy  must  be  developed  from  the 
end  user  perspective.  The  techniques  employed 
must  be  attainable.  The  strategy  must  be 
implemented  in  an  evolutionary  manner  with  small 
"doable"  modules.  The  progress  from  existing 
capabilities  to.those  of  the  target  architecture 
must  be  clear. 

A  statement  of  need.  A  Statement  of 
Operational  Need  (SON),  drafted  at  HQ  TAG  in  August 
1985,  attempted  to  squeeze  force  level  automation 
into  a  program  (a  Class  IV  modification)  to  replace 
the  T.'VCC's  AN/TSQ-92  shelters  with  more  supportable, 
smaller,  expandable  hard  shelters. 

This  proposed  program  ($37+  million), 
would,  for  example: 

1.  Internet  an  intricate  multi-level  secure 
voice/data/video  system  of  LANs  using  24 
shelters  (12  for  each  Numbered  .^ir  Force). 

2.  Fully  interconnect  with  all  subordinate  and 
lateral  T.'VCS  elements  (e.g.,  CRC,  AWACS, 
ASOC,  woe,  and  ABCCC). 


3. 


Employ  gateways  for  full  two-way  data 

information  exchange  with  Army,  Navy, 
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Marine,  and  allied  forces  tactical  C  ,  air 
defense,  and  fire  control  systems. 

4.  Provide  AI  based  decision  and  task  aids. 

5.  Incorporate  all  DoD  standard  protocols 
within  the  LANs. 

Each  shelter  would  have  its  own  secure 
LAN,  be  tied  to  a  medium  area  network,  and  be 
separated  from  adjacent  shelters  at  distances  up  to 
3000  feet.  Each  fiber  optic  LAN  would  support  secure 
information  exchanges  among  one  32 -bit 
minicomputer,  six  microcomputers,  six  intercom 
telephones,  four  graphics  workstations,  one 
television  monitor,  and  two  large-screen  displays 
within  a  shelter. 

Prototype  testing  would  be  accomplished  at 
Rome  .Air  Development  Center  (R.ADC) ,  with  a  final 
3-month  field  test  conducted  at  the  507th  T.ACCS.^^ 
The  SON  obviously  missed  the  point;  its 
processing  was  desisted  when  T.ACC  matters  were 
assumed  by  HQ  TAC/DOY. 

RECOMMENDATION.  TAG  SHOULD  ADOPT  AN 
EVOLUTIONARY  STRATEGY  IN  THE  DEVELOPD^iENT  AND 
ACQUISITION  OF  A  FUTURE  FORCE  LEVEL  C^  SYSTEM. 


RECOMMENDATION . 


KEEP  CAFMS  ALIVE  ONLY 


UNTIL  A  CORE  SYSTEM  CAN  BE  FIELDED:  TARGET  FOR  EARLY 
1987. 


Summan 


The  Air  Force  FY  1986  procurement  budget 

for  Tactical  Air  Control  System  Improvements  is 

$95.4  million.  For  FY  1987  it  is  $161.7  million. 

Over  $52  million  has  been  budgeted  for  the  field 

testing  of  AS,\S/ENSCE  modules  during  FY  86  and  FY 

87,  under  the  Joint  Tactical  Fusion  Program.  There 

are  no  funded  programs,  however,  for  tactical  force 
2 

level  C  .  Programs  such  as  MCE  will  continue  to 
soak  millions  while  users  seethe  over  their  existing 
state  of  readiness. 

Operational  commanders  could  not  be 
expected  to  tolerate  an  obsolete,  highly  vulnerable 
system  such  as  C.4.FMS  anymore  now  than  on  the  future 
battlefield. 

It  is  the  nature  of  command  and  control 

systems  and  the  series  of  past  failures  experienced 

2 

in  attempting  to  detail  C  requirements  "up  front" 
that  have  motivated  a  new  w'^y  of  thinking  in  command 
and  control  systems  acquisition.  EA  embraces  the 
idea  that  the  user  is  a  significant-to-dominant 
player  in  the  acquisition  process.  The  user  who  has 


r 

K-MK  £56  REQUIREHENTS  OEEINtTION  FOR  FORCE  LEVEL  COHNflND  MID 
CONTROL  IN  THE  TACTIC  <U>  AIR  FORCE  INST  OF  TECH 
NRIGHT-PATTERSON  AFB  OH  C  J  BOENSCH  1985 

UNCLASSIFIED  AFIT/CI/NR-86-MT  F/0  17/2 

NL 

r 

i 

1 

1 

■ 

1 

§ 

1 

t 

1 _ j 

worked  in  the  hectic,  largely  manual  TACC  operation, 
assisted  by  CAFMS  doesn't  know  what  functional 
requirements  state-of-the-art  technology  can  or 
should  support  until  he  has  had  a  chance  to 

1 3 

understand  the  technology  through  operational  use. 

A  Solution 

A  Rapid  Requirements  Definition  Capability 
(RRDC)  is  the  solution  to  this.  The  AFCEA  Study: 

In  concept,  RRDC  can  be  assembled  since  it 
can  be  put  together  using  off-the-shelf 
technology.  The  objective  is  to  design  an  RRDC 
flexible  enough  ...  so  that  user  "experience" 
can  be  quickly  obtained,  and  a  system  concept, 
architecture,  and  a  set-  of  initial  ("core") 
capabilities  can  be  developed. 

Sub- recommendation .  A  RAPID  REQUIREMENTS 

DEFINITION  CAPABILITY  (RRDC)  IS  THE  ESSENTIAL  MEANS 
BY  WHICH  A  CORE  SYSTEM  WILL  QUICKLY,  MORE 
ACCURATELY,  AND  MORE  INTELLIGENTLY  BE  SPECIFIED. 

An  RRDC  is  a  test  bed  as  well  as  a 
prototype  in  this  document.  There  are  technical 
differences,  but  too  many  reports,  studies,  and 
other  documents  have  used  these  terms  synonymously. 
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CHAPTER  V 


REQUIREMENTS  DEFINITION  OF  THE  CORE 
INCREMENT:  GENER.^L  STRATEGY 


Get  hard  data.  Get  it  quickly.  That's  the 
key. 

--A  Passion  for  Excellence 


Program  Management 

This  paper  considers  the  RRDC  to  be  the 
appropriate  means  from  which  an  operational  core  is 
to  be  specified.  This  chapter  discusses  general 
considerations  in  the  implementation  of  a  test  bed 
and  recommends  some  reasonable  criteria  that  the 
RRDC  should  fulfill. 

The  successful  definition  of  the  functional 
requirements  for  a  core  increment  to  be  fielded  is 
contingent  upon  a  well-managed  requirements  defini¬ 
tion  study  period. 


Experience  has  shown  that  even  when  individuals 
are  capable  of  accurately  envisioning  how  a 
system  would  operate  (as  a  result  of  prior 
experience,  education,  and  training)  their  ideas 
change  substantially  after  "hands-on" 
experience. 
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The  TAP'S  experiences  with  CONSTANT  WATCH,  EIFEL, 
and  CAFMS,  with  their  varying  degrees  of  success, 
will  undoubtedly  serve  well  during  such  a  study,  and 
the  lessons  learned  during  their  stages  of 
implementation  should  be  actively  considered.  While 
the  "hands-on”  experiences  with  CONSTANT  WATCH, 
EIFEL,  and  CAFMS  may  well  allow  a  higher  quality 
specification  for  a  core  increment,  the  limitations 
imposed  by  their  architectures  and  the  ways  they  are 
employed  preclude  any  dominant  influence. 

Planning,  Programming,  and  Budgeting 

To  adopt  an  evolutionary  strategy  in 
acquiring  a  command  and  control  system  is  going  to 
require  program  visibility  and,  especially,  the 
emphasis  from  top-level  management  within  the  T.\F. 

An  RRDC  could  be  established  in  relatively 
short  order  with  such  emphasis.  The  basis  for  this 
decision  would  be  a  short  statement  of  operational 
requirements  and  a  general  description  of  the 
functional  capability  desired  for  the  full  system, 
an  obvious  deviation  from  the  norm. 

The  study  period.  Concurrent  with  system 
planning,  a  Requirements  Definition  Study  Period 
(RDSP)  based  upon  an  acquired  test  bed  system  (the 
RRDC)  would  serve  to  define  the  specific 
requirements  of  a  core  system.  These  requirements. 
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documented  in  a  revised  SON  and  stating  also  the 

general  overall  program  requirements,  would  provide 

the  basis  for  budgeting  in  such  a  strategy.  System 

acquisition  would  then  follow  a  "design-to- 

approved-budgeting"  path,  which  is  considered  a 

better  estimate  of  the  system's  actual  cost  than 

2 

those  taken  in  traditional  approaches. 

Forward  funding  of  the  core  increment  and 
two  subsequent  increments  would  allow  the 
implementation  of  the  core  system  shortly  following 
the  RDSP  and  fill  the  present  two-year  PPBS  gap. 

It  would  allow  the  fielding  of  an  operationally 
usable,  tactical  battle  management  system  in  1987 
rather  than  in  1992.  Money  saved  in  the  maintenance 
of  C.\FMS  alone  would  pay  for  the  initial  system. 

Funding  strategy.  The  basic  EA  model  calls 
for  the  sequential  fielding  of  operational 
capabilities  as  the  system  evolves.  If  each 
increment  were  treated  as  a  "release"  within  the 
overall  requirement,  decision  for  funding  of  future 
increments  could  be  determined  on: 

1.  Reports  of  system  performance  and  user 
satisfaction,  from  9th  and  12th  Air  Force 
commanders , 

2.  Other  measures  of  merit, 
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3.  Definition  of  future  increments,  and 

4.  Management  of  the  program. 

Sub- r ecCTmnendat ion .  A  FORMAL  MANAGEMENT 
ELEMENT,  WHOSE  PRIMARY  MISSION  IS  THE  OVERALL 
MANAGEMENT  OP  THE  EA  PROGRAM — TO  INCLUDE  THE  RAPID 
REQUIREMENTS  DEFINITION  CAPABILITY — IS  PARAMOUNT  TO 
A  SUCCESSFUL  ACQUISITION  STRATEGY. 

The  Program  Management  Office 

A  Program  Management  Office  CPMO)  should  be 
established  at  Headquarters,  Tactical  Air  Command, 
under  the  auspices  of  the  Deputy  Chief  of  Staff, 
Operations.  The  PMO’s  formalization  would  logically 
be  later  contained  in  a  Headquarters,  USAF  Program 
Management  Directive.  Headquarters,  Tactical  Air 
Command  would  thus  be  designated  the  implement ing 
command  and  assigned  overall  program  management  for 
the  project.  Headquarters  TAC  would,  through  a 
designated  Program  Manager,  have  overall  management 
responsibility  for  organizing,  planning,  directing, 
and  controlling  the  project. 

A  combined  program  office.  .Actually,  the 
PM  would  be  in  charge  of  a  "combined  program 
office."^  Such  an  office  would  be  comprised  of  the 
HQ  TAC  PM  team  with  representation  from  the  user, 
developer,  and  tester  communities. 


The  roles  and  relationships  among  HQ  TAG, 
AFOTEC,  contractors,  TAFIG,  AFSC,  AFLC,  PACAF, 
USAFE,  ATC,  ESC,  MAC,  the  Air  Staff,  and  others 
possibly  involved  in  the  program  must  be  negotiated 
early.  Overall  responsibility  for  defining  the 
particular  evolutionary  approach  to  be  taken  would 
rest  squarely  with  the  PMO. 

If  an  evolutionary  acquisition  strategy  is 
to  be  implemented  with  any  degree  of  success,  it 
should  be  surmised  from  previous  experience  that  the 
PMO  is  the  cornerstone  of  its  success.  A  cadre  of 
experienced,  highly  proficient  officers  from  a 
variety  of  backgrounds  would  be  an  intelligent 
selection  decision.  The  most  effective  teams  are 
those  comprised  of  many  disciplines. 

Sub- recommendation .  CONCERTED  EFFORT  MOST 
BE  HADE  TOWARD  ASSEMBLING  AN  RRDC  THAT  ^  RAPIDLY 
ACQUIRED.  COMMERCIALLY  AVAILABLE  "OFF-THE-SHELF" 
SOFTWARE  AND  HARDWARE  AND  CCXIPETENT,  AGGRESSIVE 
PROGRAM  MANAGEMENT  ARE  FUNDAMENTAL  TO  THIS  EFFORT. 

The  combined  team  would  do  well,  in  the 
beginning,  to  consider  12  basic  questions  posed  by 
John  C.  Morgenstern,  in  the  May  1983  issue  of 

4 

SIGN.^L.  Such  questions  as  ".\re  we  pushing  the 
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state-of-the-art?  Do  we  have  to?  Can  we  afford 
to?"  would  seem  basic  for  a  test  bed  project. 

Acquisition  planning,  configuration 
management  (software  and  hardware)  planning,  test 
bed  development  and  maintenance,  and  system 
architecture  planning  are  a  few  areas  that 
contracted  support  would  prove  beneficial  in  an  EA 
effort.  This  is  revealed  further  in  Chapters  VI  and 
VII. 

Competition 

Competitive  acquisition  of  services  and 
products  should  be  used  to  the  extent  appropriate, 
given  the  requirement  to  maintain  minimum  disruption 
of  the  system's  evolution.  As  normal  contracting 
practices  could  cause  unacceptable  delays  to  be 
incurred,  resulting  in  overall  substandard  system 
performance,  it  is  imperative  that  government  and 
contractor  responsibilities,  particularly  in  the 


areas  of 

1.  Test  bed  development, 

2.  System  architecture, 

3.  .Acquisition  planning,  and 

4.  Configuration  management 

be  determined  at  the  project's  inception.  It  must 
be  emphasized  that,  in  those  areas  continuing 


throughout  the  system's  lifetime,  frequent  con¬ 
tractor  changes  would  be  disruptive  and  counter¬ 
productive. 


RRDC  Specification 
Prerequisite  Criteria 

Software  first.  "Swallowing  the  elephant 
whole,"  "creating  a  many-humped  camel,"  and  "trying 
to  do  all  things  for  all  people"  are  three  of  the 
pejorative  phrases  Air  Force  officers  use  when 
describing  requirements  definition.  It  seems  to  be 
a  natural  tendency  to  add  requirements  to  a  system 
as  documentation  "floats"  through  staff  coordination 
channels.  An  inexpensive  twisted  pair  based  data 
LAN  thus  ends  up  as  a  fiber  optic  based  integrated 
voice,  data,  and  video  LAN.  Chartering  the  PMO  with 
the  RRDC  specification  and  adopting  a  "software 
first"  perspective  will  mitigate  this  effect. 

Sub- recommendation .  START  SMAUj  . 

Affordability.  The  RRDC  needs  to  be 
affordable.  The  expected  benefit  of  a  particular 
characteristic,  hardware  or  software,  must  be 
subjectively  evaluated  against  the  expected  value  of 
its  contribution  to  the  core  increment. 
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Criteria  definition.  The  attributes  of  a 
viable  prototype  system  have  been  synthesized  from 
several  sources: 


Formal  and  informal  statements  of 
requirements  from  operational 
commanders  at  the  Numbered  Air  Forces 
Current  and  future  planned  employment 
concepts . 

Evaluations  of  presently  fielded 
tactical  C  systems  (see  Chapter  VI), 
Reasoned  judgment. 


Operational  Criteria 

Operational  criteria  are  the  "mind 
extending"  attributes  of  a  command  and  control 
system  and  are  software  critical. 

The  software.  Software  must  be  acquired 
commercially  "off  the  shelf"  or  from  government 
sources.  All  basic  applications  software  must  be 
fully  integrated  and  judged  "user  friendly"  without 
modification.  Software  shall  be  required  to 
support,  as  a  minimum,  the  following  functions: 


m 
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Information  Processing: 

a.  Message  drafting  and  editing,  the 
principle  message  being  the  Air 
Tasking  Order. 

b.  User-defined  message  format 
specif icat ion . 

c.  User-defined  display  symbol 
sped  f  icat  ion . 

d.  Message  processing  and  switching: 

1)  Multiple  addressing  of  messages. 

2)  .Automatic  routing,  notification, 
and  storage  of  inter-  and 
intra-module  message  traffic. 

3)  Automatic  store  and  forward  of 
message  traffic. 

4)  .Automatic  prioritization  of 
messages  by  user-defined  cate¬ 
gories  defined  by  the  user  (e.g. 
Flash  precedence). 

5)  .Automatic  notification  and 
printing  of  priority  messages. 

6)  .Automatic  protocol  and  transmis¬ 
sion  medium  conversion  for 
specified  protocols  and  links. 

7)  Error  detection  and  automatic 


retransmission . 


e.  Off-line  local  processing  and 

programming  capability. 

1)  Workstation  must  be  capable  of 
running  MS-DOS/PC-DOS 
applications . 

f.  Data  base  management: 

1)  Automatic  duplication  of  data 
base  information  (redundancy)  at 
specified  modules,  partitioned 
according  to  job  functions/ 
locations . 

2)  Storage  of  force  status 
information  and  messages  (e.g., 
aircraft  status,  munitions 
status) . 

3)  Force  information  and  message 
retrieval  via  query  language  or 
predefined  queries. 


Information  Exchange: 

a.  Net  control/maintenance  of  primary  and 
secondary  network  topologies. 

3.  High  speed  intramodule  throughput. 

:.  .'Vutodial/autoanswer  modem  capability 
with  1200  bps  minimum  modem  speed. 
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d.  On-line,  system  high  encryption 
capability  between  modules,  using 
Government  Furnished  Equipment  (GFE) . 

Information  Presentation: 

a.  Display  of  maps  and  situation  outlays. 

b.  Selection  of  map  size,  type,  and 
number  of  units  to  be  displayed,  as 
defined  by  the  user. 

c.  Retrieval  of  unit  information  via 
selection  of  unit(s)  from  a  screen 
display  (i.e.,  "hooking  capability"). 

d.  Automatic  preparation  of  automated 
briefing  materials  from  information  as 
it  is  received  (in  a  user  defined 
format) . 

e.  Presentation  of  automated  briefing  via 
large  screen  display  or  monitor. 

f.  Capability  to  produce  hard  copy  of 
messages,  reports,  other  text,  and 
graphics . 


Performance  Monitorability : 

a.  .Automatic  monitoring  and  reporting  of 
system  status. 

b.  System  diagnostic  routines. 


Readiness .  The  test  bed  system  must 
provide  a  viable  operational  capability.  It  should 
be  configured  to  allow  peacetime  training,  normal 
in-station  office  automation  uses,  and  operational 
planning.  The  system  must  be  capable  of 
transitioning  from  peacetime  use  to  meet  contingency 
or  other  deployment  conditions,  as  determined  by  the 
PMO.  System  readiness  shall  be  considered  an 
important  system  criterion  in  determination  of  core 
system  requirements. 

Flexibility.  The  system  must  be  designed 
to  allow  ground  elements  to  operate  in  existing 
fixed  facilities  Ce.g*,  hangers,  bunkers, 
buildings),  mobile  shelters,  or  tents  at  a  deployed 
location.  Modularity  must  be  basic  in  the  system 
design,  allowing  the  system  to  be  tailored  to  a 
given  scenario  and  modularly  expanded/decreased 
without  disruption. 

The  RRDC  should  be  configurable  to 
interface  initially  with  the  LENSCE,  the  BCE,  the 
ASOC,  the  WOCs ,  and  the  ABCCC. 

Maintainability.  Emphasis  must  be  placed 
on  acquiring  test  bed  hardware  of  proven  reli¬ 
ability,  designed  to  require  minimum  field 


maintenance.  "Remove  and  replace"  Air  Force 
maintenance  will  be  considered  a  key  logistics  study 
area  in  the  requirements  definition  study. 

Supportability .  Supportability  is  closely 
related  to  maintainability,  and  will  be  considered 
another  key  logistics  study  area  in  the  requirements 
definition  study.  Supportability  considerations 
might  include  the  following: 

1.  Reduction  in  personnel  requirements. 

2.  Reduced  dependency  on  fossil  fuels. 

3.  Design  of  individual  modules  for  self- 

contained  operation. 

4.  Lightweight  organic  power. 

Special  arrangements  will  be  made  during 
the  study  to  ensure  appropriate  hardware  and 
software  support  through  commercial  and  government 
channels . 

Reliability.  Full  military  specifications 
CMILSPECs)  will  not  be  used  as  system  criteria  and 
would  defeat  the  main  acquisition  strategy  for  the 
RRDC:  to  acquire  affordable,  commercially  available 
hardware.  Modifications  of  hardware  will  be  made 
consistent  with  the  operational  and  system  criteria. 


elements  of  the  system  may  be  developed  to  support 
operations  while  mobile.  All  system  hardware,  to 
include  power  generation  equipment,  must  be  air 
transportable  by  C-130  and  C-141.  All  system 
elements  must  be  developed  to  be  set  up  and 

operational,  exclusive  of  non-organic 
communications,  within  one  hour  of  arrival  on  site. 
Similarly,  the  RRDC  must  be  capable  of  rapid  tear- 
down  and  redeployment. 

Survivability.  The  above  criteria  greatly 
impact  on  survivability.  The  following  are  some 
further  areas  to  be  studied  in  the  test  bed: 

1.  Ruggedization  of  system  hardware. 

2.  Redundancy/partitioning  of  data  and 
operations . 

3.  Dispersal  of  modules, 

4.  Site  security. 

5.  Low  Probability  of  Intercept/Low  Proba¬ 
bility  of  Exploitation  of  Communications. 

6.  Other  passive  defense  measures: 

--Low  noise,  low  infrared  signature 

generators . 


--Site  locations. 
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--Camouflage,  concealment  techniques, 


-Mobility . 


Training.  Training  is  a  chronic  problem 


within  the  Tactical  Air  Control  Center.  The  test  bed 


will  examine  methods  of  reducing  requirements  for 


training;  ease  of  learning  software  applications  of 


the  RRDC  is  essential.  Possible  areas  in  training 


to  be  studied  include  the  following: 


1.  Built-in  training  routines. 


2.  Computer  Assisted  Instruction  (CAI). 


3.  Interactive  video. 


An  active  search  will  undoubtedly  uncover  exciting 


uses  of  these  training  techniques.  Contact  should  be 


made  with  the  Air  Force  Human  Resources  Laboratory. 


RADC,  Air  Training  Command,  civilian  contractors. 


and  others,  to  assist  in  the  study  (see  Chapter 


VII). 


It  is  anticipated  that  initial  training  on 


the  RRDC  would  be  provided  to  selected  HQ  TAC  staff 


personnel,  PMO  personnel,  and  selected  users,  both 


at  Langley  and  at  users'  operating  locations 
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REQUIREMENTS  DEFINITION  IN  THE  ARMY  AND  MARINE 
CORPS:  EA  CASE  STUDIES  AND  IMPLICATIONS 
FOR  INTEROPERABILITY 

Military  strategy  that  loses  battles  is  no 
more  disastrous  than  acquisition  strategy  that 
fields  obsolete  systems.  The  final  outcome  very 
well  can  be  the  same. 

--Lt  Gen  Emmett  Paige,  Jr.,  USA 

The  Test  Beds 

Two  particular  cases  of  evolutionary 
approaches  to  requirements  definition  and  system 
implementation  are  reviewed  in  this  chapter.  The 
first  involves  efforts  of  the  Army  to  develop  and 
acquire  a  distributed  tactical  command  and  control 
system.  Previously  called  the  Distributed  Command 
and  Control  System- -now  designated  Maneuver  Control 
System  (MCS)  2.0--it  has  been  cited  as  a  ’’paradigm 
for  future  system  acquisition  and  development."^ 
MCS  2,0  is  presently  managed  by  the  Army  Development 
and  Employment  Agency  (ADEA) ,  Ft.  Lewis,  Washington. 
Together  with  the  9th  Infantry  Division  (Motorized) 
and  the  Army  Communications  Electronics  Command, 
Center  for  Systems  Engineering  and  Integration,  ADEA 


has,  in  less  than  3  years,  fielded  an  affordable, 
flexible,  modular,  transportable,  survivable, 
automated  tactical  command  and  control  system.  It 
is  the  first  such  major,  deliberate  effort  among  the 
services  to  acquire  and  develop  such  a  system, 
exploiting  commercially  available  software  and 
hardware  as  a  basis. 

The  second  system  discussed  is  a  recent 
initiative  of  the  Marine  Corps  to  acquire  and  field, 
under  the  auspices  of  the  Marine  Corps  Development 
and  Education  Command,  a  command  and  control  test 
bed  at  Camp  Pendleton,  California. 

The  Marine  Corps  program  is  called  the 
Tactical  Combat  Operations  CTCO)  Test  Bed,  and  is 
operationally  supported  by  the  1st  Marine  .Amphibious 
Force  (I  MAF)  headquartered  at  Camp  Pendleton.  The 
TCO  Test  Bed  is  an  attempt  to  validate  and 
revalidate  functional  requirements  of  its  formal  TCO 
program  (another  lengthy  formal  program)  through  the 
acquisition  of  an  operationally  usable  C  system. 
The  TCO  Test  Bed  system,  which  was  formally  accepted 
at  Camp  Pendleton  during  the  first  week  in  November, 
1985,  capitalizes  on  the  developments  of  ADE.A,  the 
Defense  Nuclear  Agency,  and  the  Army  corps  level 
Staff  Planning  and  Decision  Support  (SPADS)  System. 
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Essentially,  the  TCO  Test  Bed  system  is 

based  on  the  evolutionary  developments  of  existing 
2 

C  systems . 

MCS  2.0 

The  9th  Infantry  Division 

The  Maneuver  Control  System  (MCS)  2.0  is  a 
recent  redesignation  of  the  Distributed  Command  and 
Control  System  (DCCS).  The  Distributed  Command  and 
Control  System  evolved  in  the  High  Technology  Light 
Division  CHTLD]  program  at  the  9th  Infantry  Division 
C9th  ID)  at  Ft.  Lewis,  Washington. 

Meeting  AirLand  Battle  requirements. 

Through  the  establishment  of  the  Army  Development 

and  Employment  .Agency  (redesignated  from  the  High 

Technology  Test  Bed)  at  Ft.  Lewis,  the  Army  has 

built  the  mechanism  to  design  and  evaluate  how  a 

High  Technology  Light  Division  (i.e.,  the  9th  ID  at 

present)  can  meet  the  requirements  of  AirLand  Battle 

(the  .Army's  present  fighting  doctrine),  and  future 

.AirLand  Battle  doctrine. 

The  division  is  being  designed  to  possess 

the  fighting  power  of  a  heavy  division  in  the 

European  theatre,  but  with  the  strategic  and 

tactical  deployability  and  sustainability  of  a  much 
2 

lighter  force.  The  9th  ID  has  been  structured  as  a 
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"task  organized"  unit,  which  is  atypical  of  Army 
divisions.  This  structure,  not  unlike  that  of  a 
Marine  Air-Ground  Task  Force,  lets  fighting  power 
be  more  readily  tailored  to  a  particular  operation. 

Requirements  for  survivability,  synchro¬ 
nized  combined  arms  attack,  and  a  common 
perception  of  the  battlefield  in  the  AirLand  Battle 
environment  are  a  few  requirements  that  the  HTLD's 
tactical  command  and  control  system  has  had  to  be 
designed  to  support. 

The  Decs  (MCS  2.0),  deemed  the  "most 
important"  of  the  Ft.  Lewis  programs,  was 
established  in  1983  as  a  3-year  evolutionary 
acquisition  effort  toward  the  fielding  of  a 
division-wide  system,  and  as  a  means  through  which 
to  define,  test,  evaluate,  and  redefine  command  and 
control  requirements  among  all  functional  areas 
(i.e.,  maneuver,  fire  support,  intelligence/ 
electronic  warfare,  combat  service  support,  and  air 
defense)  of  the  SIGMA  ST.AR  (see  glossary). 

The  system.  The  DCCS  was  designed  as  an 
integrated  system  of  computer  hardware  and  software, 
vehicles  and  shelters,  communications  equipment, 
trained  personnel,  and  operating  procedures.  Its 
"building  block"  architecture  (an  evolution  from  the 
SPADS  system  discussed  later  in  this  chapter). 


enabling  the  flexible  and  modular  deployment  of 

system  command  and  control  elements,  together  with 

an  integrated  software  package  that  supports 
2 

numerous  C  applications,  are  the  foundation  of  the 
system.  It  is  appropriate  to  examine  the  basic 
hardware  and  software  used  in  MCS  2.0,  particularly 
because  MCS  2.0's  evolved  capabilities  have  been 
incorporated  in  the  Marine  Corps'  TCO  Test  Bed 
system. 


System  Echelons 


The  upper  echelon.  MCS  2.0  is  divided  into 
Upper  Echelon  (brigade  and  above)  and  Lower  Echelon 
module  configurations.  The  division  (Upper  Echelon) 
Tactical  Operations  Center  (TOC),  for  example, 
consists  of  12  modules,  each  module  (or  node) 
configured  as  a  multiuser  system.  The  basic  module 
consists  of  several  terminals  or  smart  workstations, 
a  videographics  subsystem,  and  a  shared  printer  or 
plotter  connected  to  a  WICAT  160  computer.^  Each 
WICAT  is  connected  to  its  own  communications 
interface  unit  (a  gateway),  providing  connectivity 
to  Upper  and  Lower  Echelon  modules.  The  Lower 
Echelon  system,  however,  is  where  Local  Area  Network 
(L,A.N)  technology  has  been  combined  with  both  rugged 
hardware  and  powerful  integrated  software  to  support 
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C  in  the  higher  threat  environment.  Discussion  of 
MCS  2.0  hardware  will  focus  on  the  Lower  Echelon, 
with  exception  of  graphics  displays  and 
videographics,  which  are  presently  used  only  at 
brigade  and  division  levels. 

The  lower  echelon.  The  Lower  Echelon  MCS 
2.0  extends  automation  to  the  9th  ID's  Maneuver, 
Field  Artillery,  Air  Defense  Artillery,  Military 
Intelligence,  Signal,  Engineer,  and  Support 
Battalions.  The  need  for  mobility  and  ruggedization 
of  information  systems  supporting  these  functions  at 
these  levels  becomes  an  even  more  important 
consideration  in  system  design  than  for  the  brigade 
and  division  command  elements.  The  Lower  Echelon 
system,  in  terms  of  its  rugged  flyaway  capability, 
hardware  design,  and  software  applications,  is  a 
much  more  impressive  system. 

Basically,  the  Lower  Echelon  MCS  2.0,  as  it 
is  presently  implemented  at  the  9th  ID,  provides  the 
battalion  commander  two  important  capabilities: 

1.  To  update  brigade  and  division  level  data 
bases  with  a  variety  of  data  Ce-g->  force 
status) . 

2.  To  support  his  command  and  control  require¬ 
ments  through  shared  data  and  software  on 
his  high  speed  LAN. 


102 


The  Lower  Echelon  MCS  2.0 

Basic  hardware  components.  The  Lower 
Echelon  MCS  2.0  LAN  is  based  on  GRiD  Systems 
Corporation  hardware,  the  typical  multi-station 
configuration  depicted  in  figure  6.1. 

The  basic  hardware  components  in  this 
configuration  are: 

1.  The  GRiD  Server.  GRiD  Server,  the 
only  commercial  mobile  file  server  on  the  market,  is 
the  heart  of  the  LAN.  Using  an  Intel  80186-based 
file  server  board,  an  Intel  80186-based 
communications  server  board,  an  Intel  8031-based 
diagnostics  processor  board,  and  an  expansion  unit 
that  provides  slots  for  additional  server  boards  and 
future  expansion,  GRiD  Server  can  accommodate  up  to 
32  simultaneous  users. 

GRiD  Server  allows  authorized  users  to 
select  from  a  large  menu  of  software  programs, 
access  shared  storage,  and  obtain  LAN  communications 
to  other  users.  Ten  MB  and  40  MB  hard  disk  drives 
are  added  (up  to  7  per  server  are  possible  at  the 
9th  ID)  as  needed  to  provide  additional  shared 
storage  for  system  users.  Figure  6.2  shows  the  GRiD 


Server. 


FIGURE  6.1  LOWER  ECHELON 
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2.  The  GRiD  Compass.  A  weight  of  only  10 
lbs  and  the  ability  to  withstand  up  to  65  G-factors 
on  any  axis  are  two  of  this  microcomputer's  distinct 
advantages  over  standard  office  equipment,  when 
considering  deployability  and  ruggedizat ion 
requirements  (see  figure  6.3). 

The  basic  GRiD  Compass  microcomputer  used 
at  the  9th  ID  has  these  features : 

--384K  bytes  of  magnetic  bubble 
(non-volatile)  memory. 

--512K  bytes  of  Random  Access  Memory  (RAM). 

--128K  bytes  of  Read  Only  Memory  (ROM), 
expandable  to  up  to  512K  bytes. 

--An  Intel  8086  16-bit  main  microprocessor 
and  an  Intel  8087  80-bit  arithmetic 
co-processor. 

--RS  232-C  and  RS  488  ports  to  support 
connection  with  a  number  of  peripherals. 

--An  80  X  25  character,  shock-resistant, 
electroluminescent  flat  panel  display. 

--User  selectable  90V-140V  or  160V-280V 
power,  at  47-66Hz. 

--Compatibility  with  both  MS-DOS  and  GRiD 
operating  system-run  programs. 
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figure  6,3  THE  GRID  COMPASS 
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--A  built-in  1200/300  bps  modem  that 
provides  access  to  GRiD  Server/GRiD 
Compass  over  standard  telephone  lines. 

3.  GRiD  Peripherals.  At  the  workstation 
(i.e.,  GRiD  Compass^  level,  rugged  360K  byte  floppy 
diskette  drives  and  a  10  MB  Hard  Disk  System  (with  a 
360K  floppy  diskette  drive)  are  used  for  additional 
storage.  Typically,  only  selected  GRiD  Compass 
workstations  use  the  10  MB  drive. 

Other  peripheral  capabilities  include  local 
(i.e.,  workstation)  printing  and  shared  printing. 

4.  The  Communications  Interface  Unit.  The 
DCIU,  standing  for  DCCS  Communications  Interface 
Unit,  is  a  multiple  link  communications  gateway 
processor.  Originally  designed  to  operate  on  the 
Space  Shuttle,  the  DCIU  is  configurable  in  both  rack 
mountable  and  "briefcase"  versions.  The  DCIU, 
though  presently  programmed  to  service  two  16  Kbps 
FM  channels,  one  1200  bps  modem  channel,  and  one 
19.6  Kbps  channel,  is  programmable  to  service  almost 
all  of  current  and  proposed  (e.g.,  TCP/IP) 
communications  protocols.*^ 

In  addition  to  multi -station  operations 
"standalone"  configurations,  or  basic  workstation 
configurations,  are  used.  Standalone  configurations 


108 


support  dispersed  and  highly  mobile  units,  such  as 
company  level  units.  In  the  standalone  mode  of 
operation,  the  GRiD  Compass  is  attached  to  a  Single 
Channel  Interface  (SCI)  unit  or  DCIU,  an  encryption 
device  (i.e.,  the  TSEC/KY-57),  and  a  combat  net 
radio  for  16  Kbps  secure  burst  transmission  to 
higher  echelons  (see  figure  6.4).  Peripherals  are 
attached  to  the  Compass  as  needed. 

The  Videographics  Subsystem 

Videographics  provide  the  commander  the 
ability  to  see  the  AirLand  Battle.  MCS  2.0  software 
and  hardware  provide  for  the  graphic  integration  of 
situation  reports. and  standard  military  or  specially 
prepared  maps  and  photographs. 

Database  update.  As  tactical  updates  are 
received  at  the  brigade  and  division  levels,  their 
data  bases  are  automatically  updated.  Graphics 
software  enables  the  commander  to  initiate  a  data 
base  query  to  identify  units,  targets,  or  other 
desired  information  based  on  data  received.  The 
videographics  system  displays  the  selected  map  or 
photo  image  and  the  queried  data  is  then  overlayed 
(using  user-identified  icons)  on  the  image. 

Common  perception  of  the  battlefield.  The 
commander  is  thus  able  to  "see,"  for  example. 
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accurate  locations  of  friendly  and  enemy  units.  As 
data  bases  are  automatically  updated  at  every  MCS 
2.0  brigade  and  division  node,  a  common  picture  of 
the  battlefield  may  be  viewed  by  commanders  in 
widely  dispersed  locations. 

In  a  recent  ADEA  summary  of  lessons 
learned,  the  following  describes  the  value  of  color 
graphics  in  visualizing  the  AirLand  Battle: 


Being  able  to  visualize  the  battlefield,  at 
multiple  locations,  as  seen  by  the  key  decision 
maker  in  the  CG's  [Commanding  General's]  Battle 
Center  provides  the  winning  edge  since  other 
leaders  or  operations  officers  may  rapidly 
appreciate  the  commander's  intent  and  timing. 
This  capability  is  the  most  significant  of  the 
combat  multipliers  for  the  division. 


Subsystem  hardware.  Hardware  components  of 
the  videographics  subsystem  consist  of  an  Aydin 
color  monitor  (there  is  a  large  screen  display  at 
the  Commanding  General's  Battle  Center),  GraphOver 
9500  video  mixer,  and  a  Sony  videodisc  player. 


The  Software 

Lower  Echelon  MCS  2.0  software  is  fully 
integrated  and  provides  an  extremely  easy  to  learn 
user  interface.^  Of  the  17  integrated  software 
applications  packages  offered  by  GRiD  Systems 
Corporation,  the  lower  echelon  module  employs  six: 
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1.  GRiDManager 

2.  GRiDWrite 

3.  GRiDPlan 

4.  GRiDFile 

5.  GRiDPaint 

6.  GRiDPlot 


In  addition  to  these  GRiD 


Applications  manager 
Text  editor 
Spreadsheet 
Database  manager 
Freehand  graphics  package 
Graphics  tool  (graph,  pie 
chart) ' 

packages,  there  are  four 


specialized  (integrated)  packages: 


1.  The  Computer-Assisted  Message  Generator 
(CAM-G). 

2.  The  Automated  Report  Generator  (ARGEN) . 

3.  The  Electronic  Mail  System  (E-MAIL). 

4.  The  Data  Automated  Video  Display  (DAViD) 
System. 

These  10  packages  comprise  the  core  of  all 
2 

lower  echelon  C  functions. 

The  GRiD  Compass  computer  has  been  designed 
to  run  programs  written  for  the  GRiD  operating 
system  (GRiD-OS)  and  the  industry  standard,  MS-DOS, 
allowing  the  user  a  tremendous  amount  of  flexibility 
in  running  applications.  File  transfer  between  both 
software  environments  is  easily  accomplished. 

The  Lower  Echelon  MCS  2.0  integrated 
software  applications  suite  is  described  in  appendix 
F. 
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The  Integrated  Command  Post  Concept 

The  idea  o£  an  Integrated  Conunand  Post 
(ICP)  was  conceived  in  early  1984  as  a  means  of 
providing  strategic  and  tactical  mobility  to  the  9th 
ID,  while  reducing  command  post  signatures  through 

g 

modular  design. 

To  date,  38  command  posts,  configured  as 
standard,  vehicle  mounted  modules,  are  used  by  the 
9th  ID,  and  have  been  selectively  employed  at 
division,  brigade,  and  battalion  levels. 


ICP  attributes.  The  I  CPs  were  designed  and 
built  to  incorporate  the  following  attributes: 


I 

■»* 
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Accommodate  AirLand  Battle  doctrine. 

Be  responsive  to  9th  ID  DCCS  (MCS  2.0)  re¬ 
quirements  . 

Provide  for  protection  of  electronic 
equipment . 

Be  highly  mobile. 

Be  capable  of  quick  erection  and  march 
order. 

Be  modular  to  the  maximum  extent  possible. 
Have  standard  elements  to  the  maximum 
extent  possible. 

Have  reduced  and  common  electronic  signa- 


9. 


Have  common  visual  profiles. 

Incorporate  human  factors  considerations. 
Have  adequate  and  reliable  power. 


10. 


11. 


Pending  delivery  and  use  of  the  Army's  new 
High  Mobility,  Multi-Purpose  Wheeled  Vehicle 
(HMMWV) ,  surrogate  ICP  vehicles  have  been  fielded 
using  the  M886  field  ambulance  vehicle. 

The  goal  of  the  ICP  project  was  to  take 
M886  vehicles,  modify  them  as  needed,  and  install 
standard  command  post  modules.  The  idea  behind  the 
ICP  project  was  that  standardized  vehicles  could  be 
clustered  in  varying  niimbers  to  provide  command  and 
control  facilities  tailored  to  the  particular 
divisional  function.  For  example,  a  Tactical 
Operations  Center  (TOC)  would  be  comprised  of  12 
vehicles;  a  Brigade  Tactical  Command  Post  would 
consist  of  4  vehicles.  A  typical  ICP  configuration 
is  shown  in  figure  6.5. 

ICP  subsystems.  Each  ICP  module  is 
actually  a  collection  of  subsystems.  A  1983  MITRE 
Working  Paper  on  ICP  configurations  specified  these 
requirements  of  a  module: 

1.  Quick-erecting  tent. 

2.  On-board  115V/60Hz  generator 

3.  Uninterruptable  Power  Supply  (UPS). 


4. 


Signal  distribution  subsystem. 

5.  Power  distribution  subsystem. 

6.  Intercom  subsystem. 

7.  Electromagnetic  Interference  CEMI)  rack. 
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8.  Digital  data  distribution  subsystem. 

The  evolution  of  ICP  subsystems  will 
provide  a  ready  solution  to  the  problem  of  portable 
aind  reliable  pcK^er  generation,  and  power  and  signal 
distribution  to  support  the  test  bed  system  outlined 
in  the  next  chapter. 

Test  Bed  Methodology 

Since  1983  the  Distributed  Command  and 
Control  System  (now  MCS  2.0)  has  undergone  a  series 
of  tests,  in  the  hands  of  the  9th  ID,  from  which 
improvements  have  been  integrated  into  subsequent 
exercises  of  the  system.  Personnel  from  ADEA  work 
closely  with  on-site  contractors  to  provide 
solutions  to  problems.  Informally,  ADEA  Project 
Managers  attribute  the  system's  rapid  evolution  to 
continuous  interaction  among  9th  ID  officers, 
competent  and  motivated  contractors,  and  the  ADEA 
staff. 

The  urgency.  There  is  an  obvious  sense  of 
urgency  in  the  exercise,  evaluation,  and  re-exercise 
effort  at  the  9th  ID.  Because  the  commander  of  the 


9th  ID  is  also  the  commander  of  ADEA,  the  same 
individual  directs--and  is  responsible  for--the 
total  test  bed  effort.  The  present  commander  is 
Major  General  Pihl. 

Although  the  various  plans  the  9th  ID  would 
be  tasked  to  support  are  largely  classified,  it  is 
safe  to  assume  that  the  division  would  be  deployed 
to  support  a  Southwest  Asia  conflict  scenario-- 
irrespective  of  its  present  status  as  a  test 
division.  The  9th  ID  has  been  organized,  and  is 
being  trained  and  equipped,  to  do  so.  This  must 
surely  contribute  to  the  sense  of  purpose  one  feels 
among  the  men  and  women  in  the  division. 

Not  unimportant,  commanders  in  the  9th  ID 
that  their  role  in  the  division's  overall 
development  is  significant.  There  is  an  unquanti- 
fiable  morale  factor  here,  a  force  multiplier  in 
itself. 

Exercise,  test,  and  evaluation.  The  9th  ID 
aggressively  exercises  MCS  2.0,  on  the  average, 
quarterly.  Division  Command  Post  Exercise  (CPX) 
CABER  FLASH,  conducted  at  Ft.  Lewis  and  in  the 
surrounding  woods,  was  held  in  August  1985.  Having 
gone  through  what  is  termed  "wart  removal,"  MCS  2.0 
was  exercised  again  in  November,  as  part  of  CPX 
CASCADE  PEAK.  Two  brigade  level  exercises  will 


further  test  portions  of  MCS  2.0,  between  CASCADE 
PEAK  and  the  February  1986  Division  CPX. 


Army  division  level  architecture.  MCS  2.0 
architecture,  after  a  successful  demonstration  of 
the  system's  capabilities  during  JCS  Exercise  BORDER 
STAR  85,  has  been  recognized  by  the  Army  as  the 
divisional  force  level  control  system  architecture. 
Somewhat  concurrent  with  this  decision  was  the 
decision  to  redesignate  DCCS  as  MCS  2.0,  so  as  not 
to  compete  with  the  Army's  formal  Maneuver  Control 
System  program  (under  development  since  1976),  The 
scheme  now  is  to  "incorporate  the  best  of  both 
systems"  and  develop  a  force  level  control  system 
that  fully  integrates 


that  information  from  each  point  of  the  SIGMA 
STAR  required  by  the  commanders  and  presents  a 
graphical  description  of  the  commander's  status 
in  maneuver,  fire  support,  air  defense,  combat 
service,  -i  And  lEW  [Intelligence/Electronic 
Warfare ] . 


ADEA  has  now  taken  on  the  roles  of  Advanced 
Technology  Test  Bed  (ATTB) ,  SIGMA  Test  Bed,  and  MCS 
Test  Bed.  ADEA  is  presently  undergoing 
reorganization  to  accomplish  these  roles  with 
existing  personnel  and  inbound  personnel  in  planned 
billets . 
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The  Advanced  Technology  Test  Bed.  The 
primary  job  of  the  ATTB  team,  a  small  cadre  of 
primarily  signal  officers,  will  be  to  identify 
future  technology  enhancements  for  the  present  MCS 
2.0,  as  part  of  the  system’s  evolution.  The  team 
will  also  study  and  develop  state-of-the-art 
capabilities  for  a  follow-on  "MCS  3.0."  Some  major 
interest  areas  being  considered  by  the  ATTB  at  this 


time  are 


Ruggedization  requirements. 

Super  lightweight  32 -bit  machines. 
Artificial  Intelligence  applications. 

Large  screen  (higher  resolution)  displays. 
Fiber  optics  applications. 

Millimeter  wave  radio  applications. 

Command  post  survivability  (IR,  Radar, 
Ballistic,  Nuclear),  and 
MCS  2.0  installations  for  helicopters  and 
heavy  forces. 


The  MCS  Test  Bed.  The  MCS  Test  Bed  will  be 
primarily  responsible  for  the  infusion  of  MCS  2.0 
software  into  the  merged  MCS.  Also,  the  MCS  Test 
Bed  will  debug  and  validate,  through  operational  use 
at  the  9th  ID,  MCS  software  as  it  is  developed  and 
released  each  July  from  the  MCS  software  development 
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facility  at  Ft.  Leavenworth,  Kansas.  MCS  software 
version  10,  to  be  released  in  July,  1986,  will 
reflect  the  first  "merged"  software. 

By  July  1986,  as  part  of  the  evolution  of 
MCS  2.0,  the  brigade  and  division  level  WICAT 
computers  will  be  replaced  with  the  Army  standard 
Tactical  Computer  Processor  (TCP),  a  ruggedized 
Hewlett-Packard  model  HP  9000.  The  HP  9000,  a 
32-bit  microcomputer,  will  support  the  Ada 
programming  language,  the  DoD  standard.  Brigade  and 
Division  level  applications,  written  in  C  language, 
will  be  sent  to  Ft.  Leavenworth  for  rewriting  in 
Ada.  MCS  2.0  and  MCS  software  should  be  fully 
merged  by  1987.^^ 

It  is  also  hoped  that  a  quick  reaction 
software  development  capability  can  also  be 
established  at  the  test  bed.  This  is  envisioned  to 
"supplement"  the  normal  18-month  software 
development  and  release  of  MCS  software.  Contracted 
software  support  and  the  use  of  end  user  tools  have 
been  discussed  as  options. 

The  SIGMA  Test  Bed.  The  SIGMA  Test  Bed 
will  manage  the  integration  of  systems  supporting 
the  points  of  the  SIGMA  STAR  Ci*e.,  maneuver,  fire 
support,  combat  service  support,  air  defense 
artillery,  and  lEW)  with  the  merged  MCS.  This  test 


bed  will  also  have  the  responsibility  of  studying 
the  evolutionary  acquisition  of  future  Army  programs 
as  they  relate  to  the  SIGMA  STAR. 


The  most  rapid  advances  in  SIGMA  system 

integration  have  occurred  in  military  intelligence. 

Sensor  information  from  the  Army's  All  Source 

Analysis  System  (ASAS)  "Brass  Board"  was 

successfully  passed  to  the  9th  ID  commander's 

display  during  JCS  Exercise  BORDER  STAR  85.^^  The 

Lightweight  TACFIRE  (fire  support)  system  will  be 

integrated  into  MCS  2.0  by  early  1986.  Planning  is 

presently  underway  to  integrate  the  air  defense 

2 

command  and  control  system  (SHORAD  C  )  with  the 

2 

merged  MCS.  Combat  Service  Support  C  is  still  in  a 

definitional  stage  and  has  not  yet  been  actively 
14 

addressed. 

The  Tactical  Combat  Operations  Test  Bed 

General 


The  Tactical  Combat  Operations  (TCO)  Test 

Bed  is  a  Marine  Corps  initiative  to  field  a  test  bed 
2 

tactical  C  system.  The  primary  objective  of  the 
TCO  Test  Bed  is  simply  to  allow  users  to  test  and 
evaluate  the  types  and  extent  of  automated 
assistance  required  in  tactical  command  and  control. 
The  strategy  taken  by  Headquarters,  USMC,  has  been 
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to  field  an  RRDC  at  the  I  MAP  at  Camp  Pendleton, 
California.  I  MAP  serves  as  the  Marine  Corps 
component  of  USCENTCOM  and  has  been  designated  U.S. 
Marine  Corps  Central  Command  (USMARCENT). 

A  13-month  requirements  definition  period 

began  officially  on  1  April  1985  and  is  scheduled  to 

end  31  May  1986.  The  study  will  culminate  in  a  set 

of  recommendations  leading  to  further  definition  of 
2 

C  automated  support.  These  recommendations  will  be 
used  to  "guide  development"  of  the  Marine  Corps' 
formal  TCO  system. 

The  formal  TCP  System.  The  formal  TCO 
system  is  a  tactical  command  and  control  system 
concept  to  provide  semi-automated  support  to  the 
Marine  Air-Ground  Task  Porce  CMAGTP).  Consisting  of 
components  of  the  Marine  Integrated  Pire  and  Air 
Support  System  CMIPASS),  and  lower  echelon 
components,  the  TCO  system  is  being  designed  to 
provide  a  capability  to  receive,  process,  store, 
display,  and  transmit  information  to  assist 
planning,  operations,  and  intelligence  functions. 
TCO  system  equipment  will  be  employed  at  all  ground 
and  air  command  echelons  of  the  MAGTP  and  is  being 
designed  to  integrate  with  MIPASS,  a  fairly  large, 
highly  complex  system. The  formal  TCO  system  is 
thus  an  extension  of  MIPASS,  a  program  that  was 


essentially  started  in  1972  (the  Required 

Operational  Capability  document  was  approved  in 

1975)  from  requirements  generated  in  a 

1 7 

non-operational  test  bed.  The  AFCEA  Study  Team 

considered  MIFASS  as  "tending  less  successful"  on 

19 

its  array  of  programs  studied. 

Background 

During  the  last  few  years  there  has  been  a 
gnawing  feeling  among  certain  senior  Navy  and  Marine 
Corps  officers  that  the  USMC  TCO  program  has 
suffered  from  a  "lack  of  consensus"  concerning 
requirements  for  command  and  control  automation, 
particularly  from  operational  elements  such  as  I 
MAF. 


One  of  the  chief  obstacles  has  been  the 
lack  of  understanding  on  the  part  of  the 
operational  commanders  as  to  how  current 
technology  can  reasonably  support  their  mission 
accomplishment.  To  overcome  this  deficiency 
Marine  headquarters  has  directed  that  an 
evaluation  by  I  MAF  be  made  using  existing  DNA 
and  Army  sponsored  state-of-the-art  Command  and 
Control  Systems. 


Beginning  in  August  1983,  liaison  was 
established  between  the  Marine  Corps  Development  and 
Education  Command  (MCDEC) ,  Quantico,  Virginia,  and 
the  DNA.  DNA  had  overseen  the  development  and 
extensive  use  of  the  Staff  Planning  and  Decision 
Support  (SP.^DS)  system  by  various  corps  and  division 
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level  Army  elements,  under  its  Dispersed  Command 
Post  (DCP)  C  concept.  The  DNA- sponsored  SPADS 
system,  based  on  commercial  hardware  and  software, 
had,  in  1984  already  been  employed  by  a  number  of 
Army  units  in  support  of  U.S.  and  allied  operations 
and  training: 

1.  V  Corps: 

--Dispersed  Command  Post  concept. 

2.  Headquarters,  U.S.  Army  Europe  (HQ 

USAREUR) : 

--USAREUR  Distributed  Decision  Aid  System 
(UDDAS). 

3.  XVIII  Airborne  Corps: 

--USCENTCOM  Tactical  Information  Control 
System  (TACTICS)  flyaway  system. 

4.  I  Corps: 

- -SPADS  General  Staff  Support  in  Korea. 

5.  Command  and  General  Staff  College: 

--Training  of  brigade,  division,  and  corps 

staff  officers. 

--Familiarization  of  automated  battle¬ 
field  C^. 

A  test  bed  approach  to  defining  TCO 
requirements  was  studied  by  MCDEC,  who  considered  it 
urgent  that  if  a  requirements  definition  study  was 
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to  be  undertaken  that  it  be  completed  by  early  1986. 

The  formal  TCO  system  Initial  Operational  Capability 

(IOC)  date  had  been  established  for  1990,  as  part  of 

the  initial  MIFASS  buy,  dictating  a  timely  imple- 

1 9 

mentation  of  the  test  bed.  The  following 
paragraph  is  extracted  from  a  letter  from  the  TCO 
Program  Director  at  Naval  Electronic  Systems  Command 
(NAVELEX)  that  explains  their  need  to  rapidly 
conclude  an  evaluation  study: 


In  accordance  with  reference  (C)  NAVELEX 
Acquisition  Plan  No.  79-13  ,  the  production  TCO 
System  will  "use  many  of  the  common  modular 
hardware  items  and  software  modules  of  MIFASS." 
The  MIFASS  development  schedule  calls  for 
finalization  of  production  equipment  quantities 
early  in  1986  in  order  to  allow  a  production  buy 
in  FY  [Fiscal  Year]  87.  If  the  equipment  for 
the  TCO  System  is  not  included  in  the  initial 
MIFASS  production  buy,  significantly  higher 
costs  will  be  incurred  by  a  separate  procurement 
of  TCO  equipment. 


Based  on  recommendations  from  the  DNA,  and 

input  from  I  MAF  (and,  at  least  informally,  .A.DEA) , 

the  Commanding  General,  MCDEC,  selected  an  RRDC  that 

takes  advantage  of  both  the  SPADS  and  DCCS 

evolutionary  developments.  HQ  USMC  concurred  with 
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the  system  during  August,  1984. 


The  System 

Essential  elements  comprising  the  GRiD 
based  Distributed  Command  and  Control  System  (i.e.. 
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MCS  2.0)  have  been  discussed.  The  SPADS  element,  as 
the  Marine  Corps  plans  to  configure  it  in  the  TCO 
Test  Bed,  is  discussed  in  this  section. 


The  general  configuration.  SPADS  is  a 
combination  of  hardware  and  software  designed  by  the 
BDM  Corporation  to  meet  a  wid^  spectrum  of  tactical 
command  and  control  needs  of  the  military  services. 
Originally  developed  in  1980-1981,  SPADS  first 
employed  Apple  II  microcomputers  and  then-available 
peripherals  to  provide  computational  and  video 
graphics  capabilities,  as  well  as  automated  data 
links  among  dispersed  command  post  cells.  Both 
hardware  and  software  have  been  continually  enhanced 
through  EA  methodology  and  SPADS  has  been  rapidly 
adapted  to  meet  the  needs  of  a  wide  variety  of  new 
military  C  users  (see  "Background,"  this  chapter). 

The  present  SPADS  system  represents  a  major 
upgrade  (now  called  SPADS  II)  from  the  old  8-bit 
Apple  system.  SPADS  software  applications  have  been 
converted  to  run  on  the  Corvus  Concept  32 -bit 
microcomputer,  the  GRiD  Compass  16-bit 
microcomputer,  and,  recently,  the  Zenith  Z-150/151 
16-bit  IBM-PC  compatible  microcomputer.  In  addition 
to  greatly  increased  processing  power  and  speed, 
video  graphics  equipment  has  been  upgraded  to 
provide  for  greater  resolution  of  current  situation 
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and  briefing  graphics,  as  well  as  videodisc 
overlays . 

SPADS,  like  the  later  GRiD  based  system, 
incorporates  a  completely  modular  design  which 
allows  a  commander  to  reconfigure  rapidly  to  meet 
his  changing  requirements.  The  module's  backbone  is 
a  Corvus  Omninet  LAN.  SP.A.DS  and  DCCS  modules  are 
configured  similarly,  with  each  module  containing  a 
Mass  Storage  Station  and  a  Communications  Gateway,  a 
n’jmber  of  Staff  Duty  Stations  (workstations)  with/ 
without  videodisc/color  graphics  subsystems,  and  an 
optional  Shared  Output  Station  (printer,  plotter). 
Figure  6.6  depicts  the  general  SPADS  configuration. 

All  hardware  is  ruggedized  and  integrated 
into  one  or  two  man  human  engineered,  transportable 
stations  that  can  be  rapidly  set  up  and  torn  down  to 
support  mobility.  Equipment  is  modified  with 
special  backplanes,  connections,  transport  cases  and 
other  items  to  provide  both  ruggedization  and 
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simplified  set-up  appropriate  for  tactical  use. 


Communications  Gateway  Station  (CGS).  The 
CGS  provides  network  control  of  data  links  within 
the  module  and  fully  automated  data  exchange 
(electronic  mail,  data  base  updates,  graphics 
updates,  etc.)  among  modules.  At  present  its 


primary  components  are  two  Corvus  Concept  32 -bit 
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FIGURE  6.6  GENERAL  SPADS  CONFIGURATION 
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microcomputers,  one  functioning  as  Network  Control 
Processor  CNCP) ,  the  other  as  Communications  Link 
Processor  (CLiP).  Both  computers  share  a  single 
keyboard  and  monitor.  The  NCP  controls  access  to 
the  LAN  and  performs  all  intra-module  file 
transfers,  updates,  and  electronic  mail  management. 
Unique  addressing  and  automatic  routing  is  provided 
to  all  users  throughout  the  local  and  wide  area 
networks.  The  CLiP  manages  eight  intermodule  data 
links  simultaneously  (expandable  in  increments  of 
four) ,  and  the  status  of  four  data  links  may  be 
displayed  simultaneously.  Other  functions  supported 
by  the  CLiP  include  the  following: 


1.  Automated  message  precedence  handling. 

2.  Management/conversion  of  multiple 
simultaneous  protocols. 

3.  300  bps  through  16  Kbps  data  rate 
capability. 

4.  Host  computer  traffic  storage  during  host 
moves  and  communications  outages. 


5.  Network  updating. 

22 

6.  End-to-end  acknowledgment  of  messages. 

The  CCS  is  integrated  into  a  single  ruggedization/ 
transport  case  with  special  cables  and  connectors  to 
provide  field  reliability  and  rapid  set-up/tear- 
down.  Figure  6.7  illustrates  the  CCS. 
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FIGURE  6.7  THE  COMMUNICATIONS  GATEWAY  STATION 
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Staff  Duty  Station  CSDS).  The  SDS  provides 
each  user  with  input/output,  processing,  and  display 
capabilities  through  access  to  all  SPADS  software. 
On  the  Omninet  a  workstation  may  be  the  Corvus 
Concept  32-bit  microcomputer  or  a  Zenith  Z-150/151 
16-bit  microcomputer  (or  other  IBM-PC  compatible 
machine).  The  Apple  II  is  also  supported,  making 
SPADS  "backward  compatible"  with  earlier  increments. 
Other  components  of  the  SDS  include  a  local  printer, 
local  storage,  and  a  videographics  subsystem 
package.  Figure  6.8  shows  the  SDS  (a  Corvus  Concept 
microcomputer) . 

Mass  Storage  Station  (MSS)  .  The  MSS 
provides  data  sharing  and  transfer  within  the  module 
via  the  LAN.  In  SPADS'  present  stage  of  evolution, 
its  primary  components  are  a  20  MB  or  40  MB 
(nominal)  hard  disk,  a  disk  server,  and  an 
Uninterruptible  Power  Supply  (UPS).  A  digital 
voltmeter  provides  constant  monitoring  of  Omninet 
voltage  so  that  problems  may  be  detected  before 
electronic  components  are  damaged.  These  components 
are  integrated  into  a  ruggedization/transport  case 
with  special  connections  to  the  Omninet  and  for 
power. 

Videodisc/color  graphics  package.  Any  SDS 
may  be  connected  to  a  videodisc/color  graphics 
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FIGURE  6.8  THE  STAFF  DUTY  STATION 


package  to  provide  high  resolution  color  graphics, 
including  overlays  on  stored  map  frames  and 
photographs.  Major  components  are  the  GraphOver 
9500  graphics  mixer,  an  industrial  quality  videodisc 
player,  appropriate  interface  mechanisms,  and  either 
a  high  resolution  RGB  color  monitor  or  video 
projector  with  large  screen  display. 


Shared  Output  Station  (SOS).  The  SOS 
provides  high  speed/high  quality  printing  (to 
include  monochrome  graphics)  to  all  users  within  the 
module.  Overlays  and  other  large  color  graphics 
hard  copy  can  also  be  provided  through  an  optional 
plotter  controlled  by  the  SOS.  The  primary 
components  of  the  SOS  are  a  microprocessor  which 
serves  as  a  despooler  and  a  printer  Cplus  plotter  if 
desired).  Hardware  and  software  interfaces  allow 
for  the  automatic  printing  of  designated  items,  such 
as  Flash  traffic,  and  audible  notification  of  high 
precedence  output. 


SPADS  software.  SPADS  software  is  very 
similar  to  the  DCCS/MCS  2.0  software  previously 
described.  Like  the  Lower  Echelon  MCS  2.0 
applications  software,  all  SP.\DS  software  is  fully 
integrated.  Similar  information  exchange/processing 
and  decision  support  capabilities  exist  in  both 


systems.  SPADS  as  a  C  system  is  more  mature  than 
DCCS,  and  at  present  it  provides  the  user  certain 
features  not  available  with  the  GRiD  based  system: 


1.  Common  area  maintenance  of  a  multinode, 
multidrop  network. 

2.  Fully  automatic  message  routing. 

3.  Automatically  triggered  spreadsheet  and 
graphics  updates. 

All  SPADS  applications  have  been  written  in  PASCAL; 
Ada  is  clearly  the  future  SPADS  language,  however. 

TCP  Test  Bed  Implementation 

Program  management.  The  TCP  Test  Bed, 
physically  located  at  Camp  Pendleton,  is  under  the 
program  management  of  the  TCP  Development  Project 
Pfficer  (DPP),  MCDEC,  Quantico,  Virginia.  The 
system  user,  I  MAF,  will  maintain  the  dominant  role 
in  the  test  and  evaluation  of  the  system,  under  the 
direction  of  the  I  MAF  Information  Systems 
Management  Pfficer,  MCDEC s  evaluation  site 
representative.  Headquarters,  Fleet  Marine  Forces, 
Pacific,  has  given  the  TCP  Test  Bed  an  obvious 
priority  and  has  willingly  made  available  personnel 
and  material  resources  to  support  its  overall 
mission.  Contractor  services  were  procured  to 
meet  the  following  general  support  requirements: 


1. 


Procure,  integrate,  test,  and  deliver 
identified  hardware  and  software. 


2.  Provide  lessons  learned  from  previous 
systems  use  to  the  Marine  Corps  Evaluation 
Team  and  technical  assistance  for  the 
Marine  Corps  effort  to  develop  evaluation 
requirements,  objectives,  procedures,  and 
schedule . 

3.  Develop  and  deliver  necessary  system 
documentation. 

5.  Provide  technical  assistance  needed  to 
conduct  the  evaluation. 

6.  Perform  hardware  maintenance  during  the 
course  of  the  evaluation. 

7.  Provide  software  maintenance  during  the 
course  of  the  evaluation. 

8.  Provide  software  support  during  the  course 

of  the  evaluation  and  modify  basic  software 
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to  support  requirements  definition. 

The  cost -plus  -  fixed  fee  contract  was 

awarded  by  the  Navy's  Space  and  Warfare  Systems 

2  3 

Command,  on  31  July  1985.  TCO  Test  Bed  hardware 


and  software  were  delivered  to  I  MAP  and  the  initial 


field  test  was  conducted  during  November  1985. 


Software  and  modification.  Modification  of 
the  electronic  mail  system  (EMS) ,  the  database 
management  system,  and  the  communications  software 
of  SPADS  has  been  performed  to  meet  the  peculiari¬ 
ties  of  the  Marine  Corps  environment  and  to  complete 
the  integration  of  the  SPADS  and  DCCS  systems.  EMS 
was  modified  to  accommodate  10  particular  Marine 
Corps  forms.  Latitude- longitude  coordinates,  in 
addition  to  UTM  coordinates  for  any  position  around 
the  globe,  have  been  incorporated  in  the  DBMS  since 
April  1985.  The  communications  software  now  allows 
transmission  over  communications  systems  presently 
employed  by  the  Marine  Corps. 


The  test  configuration.  Figure  6.9  depicts 
the  TCO  test  configuration.  As  shown,  modules  are 
located  at  the  Marine  .Amphibious  Force  CMAF)  ,  Marine 
Division,  Marine  Air  Wing,  Force  Service  Support 
Group  CFSSG)  ,  and  regimental  headquarters  levels. 
Commercial  telephone  networks  are  used,  in  addition 
to  tactical  communications,  to  provide  connectivity 
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among  modules. 

System  exercise  test  and  evaluation  is 
scheduled  to  begin  in  December  1985  and  end  31  May 


1986.  At  present,  the  plan  is  to  employ  the  test 
bed  system  at  three  major  exercises,  including  JCS 
Exercise  GALLANT  KNIGHT.  The  first  exercise  of  the 
system  is  scheduled  for  17-20  December  1985  at  Camp 
Pendleton.  It  is  considered  likely  that  the  system 
will  be  employed  during  JCS  Exercise  GALLANT  EAGLE 
(August  1986),  even  though  the  contract  period 
expires  at  the  end  of  May  1986. 

It  is  also  considered  likely  that  the  TCO 
Test  Bed  will  continue  in  existence  long  after  the 
present  contract  expires. 


The  Seventeenth  Air  Force  Cl7th  AF) 


The  capabilities  offered  by  the  SPADS  based 
USAREUR  Distributed  Decision  Aid  System  (UDDAS)  have 
been  so  impressive  that  plans  are  being  made  within 
USAFE/AAFCE  to  field  an  operational  prototype  within 
the  Sembach  Allied  Tactical  Operations  Center  (ATOC) 
and  Sector  Operations  Center  (SOC)  III  in  Germany. 
Major  General  Breckner,  17th  AF  Commander  has 
proposed  a  four-phase  program  to  automate  these 
command  centers,  using  SPADS  software  and  German 
(Diehl)  hardware.  Initially  the  LANs  within  the 
ATOC  and  SOC  will  be  Corvus  based,  employ  fiber 
optics,  and  use  Zenith  Z-151  workstations.  The 
system  will  initially  extend  to  4ATAF/CENTAG ,  US  V 
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and  VII  Corps.  As  the  system  evolves  it  will 
interface  with  EIFEL  and  extend  into  the  mobile  TAGS 
and  Army  air  defense  system,  probably  employing  DCCS 
capabilities  (similar  to  the  TCO  Test  Bed  system). 

Appendix  G  contains  a  30  May  1985  letter  to 
General  Donnelly,  CINCUSAFE,  from  Major  General 
Breckner.  Attached  to  the  letter  is  the  basic 
acquisition  plan  for  the  system. 

The  next  "generation"  SPADS  is  foreseen  to 
be  a  super-microcomputer,  UNIX-based  system  support¬ 
ing  AI  applications  and  very  high  resolution 
(1000x1000  line)  graphics.  To  date,  over  450 
thousand  lines  of  code  have  been  developed  for  SPADS 
and  DCCS,  but  DNA,  Army,  and  Navy /Marine  Corps 
funding  for  these  systems  has  not  exceeded  $10 
million  since  1981. 

Summary 

Defense  Nuclear  Agency,  Army,  and  Marine 

Corps/Navy  efforts  in  the  development  of  automated 
2 

tactical  C  systems  strongly  suggest  that  the 
evolutionary  approach  is  working.  SPADS,  originally 
conceived  by  DNA  to  test  the  Dispersed  Command  Post 
concept  in  the  NATO  arena,  will  continue  to  evolve. 
Using  commanders  have  been  and  are  pleased  with  its 
capabilities,  which  have  been  tested  and  evaluated 
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on  numerous  major  exercises,  such  as  WINTEX-CIMEX, 

REFORGER,  CRESTED  EAGLE,  and  BRIGHT  STAR. 

USAFE  is  now  actively  planning  an 

2 

evolutionary  approach  toward  C  requirements 
definition  within  the  U.S.  and  Allied  air  forces  in 
Europe . 

SPADS  was  employed  in  support  of  the  XVIII 

Airborne  Corps  during  Operation  Urgent  Fury 

(Grenada).  Described  as  a  "combat  multiplier"  by 

the  Commander,  525th  Military  Intelligence  Group, 

2 

SPADS  supported  C  ,  intelligence  collection  and 

collection  management  (HUMINT  and  SIGINT) ,  and 

2  7 

intelligence  production  activities  on  Grenada. 

At  Ft.  Lewis,  Washington,  in  less  than 
three  years,  a  division  level  force  control 
architecture  has  been  developed,  fielded,  and 
validated  as  the  Army  standard.  And  the  evolution 
continues.  By  the  summer  of  1986,  for  example, 
brigade-  and  division-level  automation  will  be 
substantially  upgraded,  with  replacement  of  the 
WICAT  computer  with  the  Army  Tactical  Computer 
Processor  (TCP),  the  HP  9000.  MCS  2.0  and  MCS 
software  will  be  fully  merged  during  1987.  Total 
System  Tactical  Validation,  the  purpose  of  which  is 
to  fully  integrate  SIGMA  STAR  functions  into  a  fully 
merged  MCS,  will  begin  formally  in  1987.  As  the 
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Army  seeks  to  identify  a  standard  battalion  level 
workstation,  the  present  surrogate  (the  GRiD 
Compass)  and  the  GRiD  Server  will  continue  to  be 
fielded  to  all  battalions  of  the  9th  ID. 

GRiD  Compass  and  GRiD  Server  are  expected 
to  be  commercially  marketed  by  GRID  Systems  as  full 
32-bit  machines  by  fall  1986.^® 

As  both  a  cost-saving  and  test  and 
evaluation  measure,  I  MAP  is  using  the  Zenith 
Z-150/151  (purchased  in  mass  by  the  Navy  and  Air 
Force)  on  its  test  bed  system,  in  addition  to  Corvus 
SDSs.  Both  Type  A  (SPADS)  and  Type  B  (DCCS)  modules 
will  support  these  microcomputers  and  their 
applications.  The  Marine  Corps  has  made 
considerable  progress  in  running  JINTACCS  (Joint 
Interoperability  of  Tactical  Command  and  Control 
System)  Automated  Message  Preparation 
System- -J.4MPS- -  software  on  the  MS-DOS. 

RECQglMEMDATIOH .  EXPLOIT  THE  PROVEN 
CAPABILITIES  OF  EXISTING  COMMAND  AND  CONTROL  SYSTEMS 
AND  AGGRESSIVELY  TEST  COMPATIBILITY  AND 
INTEROPERABILITY  IN  "HANDS-ON"  EXPERIMENTS. 

The  success  of  these  programs,  the  proven 
capabilities  of  the  systems  they  employ,  the  planned 
evolution  of  these  systems,  their  affordability,  the 
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expanding  knowledge  and  experience  base  being  built 
through  their  employment,  the  potential  benefits 
from  the  application  of  their  software/hardware  as 
TAG'S  RRDC,  and  the  outstanding  potential  for  actual 
"hands-on"  experimentation,  practice,  and  learning 
in  multiservice/multinational  environments  are  all 
very  compelling  reasons  to  take  such  action. 

Sub-recoimnendation.  ESTABLISH  LIAISON  WITH 
ADEA,  THE  TCO  DEVELOPMENT  OFFICE  AND  17TH  AIR  FORCE. 
PLAN,  EXERCISE,  TEST,  AND  EVALUATE  THE  RRDC  IN  JOINT 
AND  COMBINED  EXERCISES. 

Chapter  I  mentioned  the  progress  that  could 
be  made  in  defining  joint  architectures  through  such 
an  approach. 

Sub-recCTmnendation .  INVITE  THE  ACTIVE 
PARTICIPATION  OF  JTC^A  IN  THIS  EFFORT. 

Creative  exercise  planning  will  be  able  to 
accommodate  this.  It  is  likely  that  DNA  would  also 
welcome  the  opportunity  to  participate  in  a 
requirements  definition  study,  based  on  their 

2  9 

outstanding  support  to  the  Army  and  Marine  Corps. 

For  the  first  time  such  a  system  could  be 
actively  employed  in  exercise,  test,  and  evaluation 
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2 

scenarios  with  the  test  bed  tactical  C  systems  of 
other  services,  the  command  and  control  elements 
with  whom  the  TAP  will  fight  in  a  future  conflict. 
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CHAPTER  VII 


REQUIREMENTS  DEFINITION  OF  THE 
CORE  SYSTEM:  MANAGEMENT  IMPLEMENTATION  STRATEGY 

User  needs  must  drive  implementation  of  all  Air 
Force  information  systems. 

- -Air  Force  Information  Systems  Architecture 

The  Test  Bed  Location 

TAC  can  field  an  RRDC  quickly  and 

incorporate  the  large  experience  base  of  other  EA 

approaches  in  the  process  of  developing  functional 

2 

requirements  for  its  future  force  level  C  system. 
MCS  2.0,  the  TCO  Test  bed,  and  17th  .^F  systems  will 
be  "transportable"  to  meet  TAC's  RRDC. 

TAC's  approach  would  necessarily  be 
different  from  that  of  the  Army  or  Marine  Corps, 
however.  There  are  just  two  TACCs  in  the 

contingency  TACS.  The  staffs  at  9th  and  12th  Air 
Forces  are  relatively  small,  and  it  is  doubtful  that 
either  could  supply  the  required  resources  to 
conduct  a  test  bed.  The  main  disadvantage  to 
designating  a  "lead  user"  of  the  two  Numbered  Air 
Forces  is  the  potential  bias  imposed  on  the  RDSP  by 
such  a  user  as  well  as  the  inadequate  participation 


of  the  other  user.  TAG  has  a  responsibility  to  the 
TAP,  also,  and  must  ensure  that  these  interests  are 
protected. 

RECCttIMENDATIOM .  FOSHALLY  ESTABLISH  THE  PMO 
AT  AND  CONDUCT  THE  TEST  BED  EFFORT  (RDSP)  FROM 
HEADQUARTERS,  TACTICAL  AIR  COMMAND. 

A  number  of  factors  support  this. 

First  of  all,  TAG  Headquarters  - -albeit  a 
surrogate  user--is  in  the  best  position  to  consider, 
evaluate,  and  integrate  user  requirements,  based  on 
9th  AF,  12th  AF,  and  7th  AGGS  involvement  Ci*e, 
"hands-on"  involvement),  into  a  core  system.  It  is 
incumbent  upon  HQ  TAG  to  ensure  that  users 

1.  Are  integrally  involved  in  all  portions  of 
the  study, 

2.  Receive  training  in  RRDG  operations,  and 

3.  Test  and  evaluate  the  system  in-station  and 
while  deployed  on  exercises. 

This  effort  would  be  managed,  however,  by  the  PMO  at 
TAG. 

Secondly,  TAG  Headquarters  has  the 
resources  to  conduct  such  a  test  bed.  A  cadre  of 

3 

G  I  professionals  could  be  assembled  from  the 
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headquarters  staff  and  headquarters  support 
organizations  to  form  a  PMO.  Facilities  are 
available  at  Langley  AFB.  Several  organizations 
reside  at  Langley  that  would  be  available  to  support 
the  PMO.  For  example: 

1.  Tactical  Air  Forces  Interoperability  Group 
(Air  Staff) : 

--Newly  formed  TAFIG  Tiger  Team. 

2.  Operating  Location  E,  Air  Force  Systems 
Command. 

3.  Army-Air  Force  Center  for  Low  Intensity 
Conflict  (see  glossary). 

4.  AirLand  Forces  Applications  Agency. 

5.  1st  Tactical  Fighter  Wing. 

6.  HQ  TAC  Staff  Organizations  (Operations, 
Requirements,  Information  Systems, 
Logistics,  Intelligence,  etc.). 

Third,  the  planning  function  exists  at  TAC 
to  schedule  exercises  of  the  test  bed  system  in  9th 
AF  CUSCENTCOM),  12th  AF  (USAFSO/LANTCOM) ,  Korean, 
NATO,  and  other  joint/combined  environments.  Top 
management  emphasis  could  see  to  it,  if  required, 
that  overall  evaluation  objectives  are  met. 


The  Management  Structure 

The  Management  Directive 

Top  management  involvement  at  TAG,  and  the 
issuance  of  a  directive  are  important  to  ensure  that 
an  EA  strategy- -an  almost  completely  novel  event -- 
remains  uncorrupted.  Such  a  directive  would  be  seen 
to  address  the  following: 


1.  The  PMO  Charter. 

2.  Establishment  of  roles  and  relationships 
among  players  (without  increasing  the 
bureaucracy) . 

3.  Conduct  of  the  EA  strategy. 

The  official  Program  Decision  Package  handed  down  by 
the  Air  Staff  would  be  foreseen  to  be  consistent 
with  this  directive. 

The  PMO  will  drive  the  system  acquisition 
and  manage  the  requirements  definition  study. 
Selection  of  the  Program  Manager  (PM)  and  the  PMO 
staff  should  begin  immediately.  An  0-6  level 
selection  committee  is  the  best  vehicle  for  this, 
with  committee  membership  drawn  from  the  HQ  TAG 


The  PM  should  report  to  the  Deputy  Chief  of 
Staff,  Operations  through  the  Assistant  Deputy  Chief 
of  Staff,  Operations. 

PM  qualifications.  Reasonable  job 
qualifications  for  the  PM  would  include  the 
following : 

1.  Be  a  Lieutenant  Colonel. 

2.  Have  operational  experience  as  a  pilot  or 
command  and  control  officer. 

3.  Have  performed  duties  in  a  TACC  and 
understand  its  present  operation. 

4.  Understand  telecommunications  and  data 
processing  Ci.e.,  information  systems) 
technologies . 

5.  Have  program  management/acquisition 
experience. 

The  Program  Management  Office 

Staff  composition-  The  "combined  program 
office"  should  be  staffed  with  officers 

I  representing,  as  a  minimum,  these  specialties: 

! 

! 

i  1.  Information  Systems  (Major,  Assistant  PM)  --  SI 

I  2.  C^  Systems,  including  airborne  systems  --DO 


3.  Tactical  Intelligence 


IN 


--DR 


4.  Requirements 

5.  Logistics  --  LG 

6.  Interoperability  --  TAFIG 

Sub-recommendation.  REQUEST  ON-SITE 
REPRESENTATION  FROM  AFSC,  AFOTEC,  AND  AFLC.  ALL 
SHOOID  BE  INVOLVED  FROM  THE  ONSET.  DEFINE 
OBJECTIVES,  ROLES,  AND  RESPONSIBILITIES  EARLY. 

The  use  of  memoranda  of  agreement,  such  as 
the  type  used  to  establish  CAFMS,  could  be  a  way  to 
avoid  counter-productive  "turf"  issues  and  get  the 
job  done.^ 

Sub-reccmnendatiOn.  ESTABLISH  LIAISON  WITH 
USERS  AND  FUND  FOR  TEMPORARY  DUTY  (TDY) 
REPRESENTATION  AT  LANGLEY. 

The  user  is  thus  involved  at  the  "field" 
level  and  at  the  PMO  level. 

The  Contractor 

The  contractor  is  integral  to  the  program 
management  team.  Procurement  of  contractor 
services  will  be  required,  obviously,  prior  to  the 
start  of  an  RDSP. 

Contractor  team  composition.  A  suggested 
minimum  contractor  team  composition  is  indicated 
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below,  based  on  tasks  to  be  performed  and  previous 
system  usage. 

1 .  Project  Manager/Contractor  Team  Leader 

a.  Three  to  five  years  of  project 
management  experience  in  programs  similar  to  the 
RDSP. 

b.  Undergraduate  academic  specialization 

degree  in  computer  sciences,  engineering, 

mathematics,  or  business  administration  with  data 
processing  specialization. 

2 .  Assistant  Project  Manager/Assistant 

Contractor  Team  Leader 

a.  One  to  three  years  project  management 

experience  in  programs  similar  to  the  RDSP. 

b.  Undergraduate  academic  specialization 

degree  in  computer  sciences,  engineering, 

mathematics,  or  business  administration  with  data 
processing  specialization. 

3.  System  Analyst  (two) 

a.  Undergraduate  degree  in  computer 

sciences,  engineering,  mathematics,  or  business 
administration  with  data  processing  specialization. 
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b.  Two  years  of  systems  analyst 

experience. 

c.  Familiarity  with  TAGS  functional 
organizations  and  their  interfaces. 

4 .  Functional  Area  Analyst 

a.  Familiarity  with  the  TAGS  and  its 
present  functions. 

b.  Two  years  of  analytical  experience. 

c.  Five  years  of  data  automation 
experience . 

5.  Data  Gommunications  Senior  Analyst 

a.  Five  years  experience  in  the 

engineering  and  development  of  computer 

communications  systems. 

b.  Undergraduate  academic  specialization 
in  mathematics,  computer  science,  electrical 
engineering,  or  a  related  field. 

c.  Experience  in  assessing  design  impacts 
of  system  software  and  hardware  interface  issues. 

d.  Gurrent  familiarity  with  radio 
frequency  (RF)  and  digital  transmission  technology. 

e.  Working  knowledge  of  practical  issues. 


«1«] 


i 


Data  Communications  Software  Procrammer 


a.  Three  years  experience  in  development 
of  software  (EPROMs  or  above)  to  support  data 
communications  interfaces. 

b.  Undergraduate  academic  specialization 
in  mathematics,  computer  science,  electrical 
engineering  or  a  related  engineering  field. 


c.  Familiarity  with  (RF)  transmissions 


technology , 


7.  Electrical  Engineer 


a.  Three  years  experience  in  data 
communications  field. 

b.  Undergraduate  degree  in  electrical 
engineering . 

c.  Familiarity  with  the  first  three 
layers  (physical,  data  link,  network)  of  the 
International  Standards  Organization  (ISO)  Open 
Systems  Interconnection  (OSI)  reference  model. 

d.  ’’Hands-on"  experience  with  the  above 
mentioned  layers. 


8.  Software  Programmer  (two) 


a.  Two  years  experience  in  software 
development  efforts  involving  integration  of  such 


applications  as  word  processing,  database  manage¬ 
ment,  and  spreadsheets  on  personal  computers. 

b.  Experience  with  GRiD  and  Zenith 
software  systems,  including  MS-DOS/multitasking 
operating  systems. 


The  RDSP  Plan 


The  RDSP  should  be  a  one-year  undertaking. 
The  plan  assumes  that  a  PMO  could  be  established  in 
less  than  three  months. 


The  Test  Configuration 

Figure  7.1  depicts  the  recommended  test  bed 
system  configuration. 


The  Evaluation  Schedule 

Five  basic  tasks,  following  the  PMO 
organization  period,  comprise  the  one-year  RDSP  Csee 
figure  7.2) ; 


1 .  Pre-Contract--Organize  PMO  .Activities. 
Activities  to  take  place  during  this  period  include: 
a.  HQ  TAG  Activities 


(1)  Establish  the  PMO. 


organizations 


(2)  Begin  liaison  with  supporting 


(3)  Contract  RRDC  support 


ABCCC 


MSS 


WS 


VP 


LEGEND 

WS 

WORKSTATION 

SOS 

SHARED  OUTPUT 

STATION 

VP 

VIDEO  PACKAGE 

MSS 

MASS  STORAGE 

STATION 

LAN 

LOCAL  AREA  NETWORK 

CLIP 

COMMUNICATIONS 

LINK  PROCESSOR 

NCP 

NETWORK  CONTROL 
PROCESSOR 

CIU 

COfWUNICATIONS  INTERFACE 
UNIT 

BCE 

BATTLEFIELD  COORDINATION 
ELEMENT 

FIGURE  7.1  THE  RDSP  TEST  BED  SYSTEM 


DELIVER  EQUIPMENT 


GALLANT  EAGLE 


FIGURE  7.2  THE  RDSP  TASK  SCHEDULE 


2 .  Task  1 - -Development  of  RDSP  Requirements 
and  Objectives.  Activities  to  take  place  during 
Task  1  include: 

a.  PMO  Activities 

(1)  Review  lessons  learned  from  DNA, 
Army,  and  Marine  Corps  exercises  with  SPADS  and  DCCS 
(MCS  2.0)  systems  employment. 

C2)  Develop  functional  requirements. 

(3)  Develop  evaluation  objectives. 

C4)  Develop  evaluation  scheme  and 
finalize  test  bed  equipment  configuration. 

(5)  Develop  RDSP  evaluation  plan. 

b.  Contractor  Activities 

(1)  Provide  procurement  services  for 
the  intended  suite  of  test  bed  equipment  (hardware 
and  software). 

(2)  Begin  equipment  configuration. 

(3)  Investigate  communications  inte¬ 
gration  requirements. 

(4)  Provide  technical  assistance  in 
the  development  of  functional  requirements, 
evaluation  objectives,  and  the  evaluation  plan. 

3.  Task  2--Modify,  Integrate  and  Test 


Equipment  Configuration.  Task  2  activities  include 


Cl)  Provide  equipment  and  support 


necessary  to  support  equipment  integration. 

(2)  Refine  and  publish  the  RDSP 
evaluation  plan. 

b .  Contractor  Activities 

(1)  Complete  equipment  configuration 
(hardware  and  software). 

(2)  Deliver  and  test  integrated 

equipment . 

C3)  Refine  equipment  integration. 

4 .  Task  5- -Develop  Documentation  and  Conduct 
Training.  Activities  to  take  place  during  this 
period  include: 

a.  PMO  Activities 

(1)  Develop,  coordinate,  and  publish 
policy  and  guidelines  for  test  bed  system  use. 

(2)  Identify  material  resources 
required  for  training. 

(3)  Identify  personnel  to  receive 
initial  system  training. 

b.  Contractor  Activities 


(3)  Prepare  and  deliver  a  training 

schedule. 

(4)  Conduct  initial  training. 

5.  Task  4--Conduct  RDSP  Exercise,  Test,  and 

Evaluation. 

Task 

4  activities  include  the 

following : 

a. 

PMO 

Activities 

CD 

Schedule  exercises. 

C2) 

Conduct  exercises  and  evalua- 

t ions . 

(3) 

Review  evaluation  results. 

(4) 

Refine  RDSP  evaluation  plan. 

C5) 

Develop  and  publish  evaluation 

reports . 

b. 

Contractor  Activities 

CD 

Provide  technical  assistance  in 

planning , 

setup , 

conduct,  and  reporting  of 

evaluation  exercises. 

(2)  Assist  evaluation  efforts. 

(3)  Provide  system  hardware  mainte¬ 
nance  and  modification. 

C4)  Provide  software  maintenance  and 


modification . 


Activities  concluding  the  study  period 


I 


'  *il 

Vl 


Report . 


include : 


PMO  Activities 


(1)  Prepare  the  RDSP  final  evaluation 


report  to  include: 


Ca)  Conduct  of  the  evaluation: 


--Schedule, 


--Problem  areas. 


(b)  Lessons  learned. 


Cc)  Identified  requirements 


of  the  core  increment. 


(2)  Publish  the  Final  Report. 


b.  Contractor  Activities 


Cl)  Assist  in  preparation  of  the  RDSP 


final  evaluation  report. 


C2)  Prepare  and  deliver  the 


contractor's  perspective  of  the  following: 


(a)  Conduct  of  the  evaluation. 


(b)  Lessons  learned. 


(c)  Identified  requirements  of 


core  increment 


Concurrent  Actions 


Planning  is  a  continuous  activity  in  EA, 
and  planning  of  the  core  increment  and  future 
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increments  must  be  concurrent  with  the  conduct  of 
the  RDSP.  The  RDSP  will  mark  the  beginning  of  the 
transition  from  the  existing  architecture  to  a 
target  force  level  architecture. 

Architecture  Study 

Contracting  of  technical  expertise  in  the 
development  of  information  systems  architectures  is 
a  preferred  approach  for  the  Air  Force  and  should  be 
procured  as  soon  as  possible  after  the  establishment 
of  the  PMO.  Frequent  change  of  contractors 
providing  architectural  development  could  seriously 
impede  and  disrupt  an  EA  approach. 

Maintaining  competition.  The  preferred 
solution  to  providing  for  competition  and  main¬ 
taining  a  smoothly  evolving  system  would  be  to  adopt 
one  of  these  approaches: 

1.  Different  parts  of  the  system  (e.g.,  TACC, 
WCC,  ABCCC)  could  be  contracted  to 
different  contractors,  undei  the  management 
of  the  architectural/systems  integration 
contractor  or  the  PMO. 

2.  Designate  the  architecture/system 
integration  contractor  as  primary 
contractor  and  solicit  competitive  bids  for 
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system  development/engineering  of  every 
other  increment. 

3.  Designate  the  architecture/system 

integration  contractor  as  the  primary 
contractor  and  require  that  various 

subsystems  be  recompeted  (e.g.,  WOC) . 

Maintaining  continuity  of  architectural/ 
system  integration  is  essential.  ADEA  has  success¬ 
fully  managed  three  contractors,  each  supporting  a 
different  aspect  of  the  test  bed,  with  minimal 
disruption.  One  contractor  manages  the  development 
of  the  Upper-Echelon  MCS  2.0  CR5D  Associates), 
another  the  Lower-Echelon  MCS  2.0  and  systems 

integration  (the  BDM  Corporation),  and  the  third 
manages  the  packet  switched  network- -this  is  not 
TRI -TAC- - (SRI  International).  The  only  drawback  to 
this  method  has  been  the  failure  to  designate  one 
contractor  as  the  primary  contractor.  All 
contractors  have  expressed  dissatisfaction  with  this 
peer-peer-peer  relationship,  but  cooperation  is 
nevertheless  high. 

Software  Configuration  Management 

This  too  is  a  dynamic,  continuous  process, 
and  should  of  course  remain  a  function  under  the 


PM*s  direction.  The  AFCEA  study  provided  this 
insight  into  software  support: 


Using  contractor  support  for  systems  using 
current  commercial  technology  (including 
software)  could  be  more  practical  (in  terms  of 
cost,  timeliness,  and  effectiveness)  than 
attempting  early  development  of  in-service 
support  resources.  This  is  particularly 
pertinent  to  facilitating  timely  deployment  of 
the  "core"  capability. 


In-house  SSF  personnel  must  remain,  at 
least  in  part,  allocated  to  supporting  CAFMS  until 
it  is  replaced.  Contractor  support  in  software 
development  and  maintenance  is  a  viable  and 
preferred  option.  Several  senior  information 
systems  officers  interviewed  felt  that,  from  their 
experiences,  strong  military  management  of 
contracted  software  support  has  yielded  positive 
results.  ADEA's  "quick  reaction"  software  support 
will  likely  be  contractor  based  and  is  intended  to 
speed  up  the  already  18-month  Army  in-house 
development  time  for  MCS  software. 


Summary 

An  RDSP  is  essential  in  defining  a  core 
system,  which  is  needed  in  the  near  term.  An  RRDC 
is  the  basis  from  which  the  core  system  will  be 


A  PMO  should  be  formed  as  soon  as  possible 
and  formalized  later.  TAG,  as  implementing  command, 
should  run  the  RDSP  and  overall  system  acquisition 


effort  through  the  PM.  The  PMO  should  be  a 
"combined  program  office."  Roles  and  responsibili¬ 
ties  among  users,  testers,  and  developers  could  be 
settled  in  memoranda  of  agreement.  These  need  to  be 
ironed  out  at  the  program's  inception. 

The  RDSP  would  mark  the  beginning  of 
serious  architectural  development.  This  must  also 

be  started  ASAP.  This  is  consistent  with  AFISA 

2 

policy  and  guidance.  As  the  force  level  C  system 
evolves  so  would  HQ  TAG'S  ability  to  define  the 
architecture  for  the  future  TAGS.  Joint 
architectural  development  could  be  furthered  through 
multiservice  exercise,  test,  and  evaluation  of  test 
bed  systems. 

This  chapter  identified  both  PMO  and 
contractor  support  elements  required  for  the  RDSP. 

A  timeline  was  established  to  fulfill  RDSP 


requirements  in  a  one  year  test  bed  effort.  It  has 


been  assumed  that,  given  the  priority  of  this 


initiative,  "color  of  money"  matters  could  be  worked 


out  for  the  near  term, 


167 


REFERENCE  NOTES 
CHAPTER  VII 

^Col  Charles  P.  Cabell,  Jr.,  USAF,  "C^ 
Systems  Development."  Symposium  speech  from  the 
author  when  he  served  as  Director,  Combat 
Information  Systems,  Deputy  for  Communications  and 
Information  Systems,  Electronic  Systems  Division, 
Hanscom  AFB,  MA. 

2 

Armed  Forces  Communication  and  Electi^nics 
Association  CAFCEA) ,  Command  and  Control  CC^) 
Systems  Acquisition  Study  Final  I^eport  [Falls 
Cnurch,  VA,  1  September  1^82),  p.  IV- 31 . 


CHAPTER  VIII 


SUMMARY  AND  DISCUSSION 


It  was  striking  to  me  that  whenever  veterans  of 
the  defense  business--the  ones  with  "dissident" 
tendencies,  the  kind  in  any  organization  who 
stop  to  look  carefully  at  things  everyone  else 
takes  for  granted- -reached  the  point,  after 
hours  of  talk,  where  they  wanted  to  move  beyond 
the  details  to  explain  what  really  troubled  them 
about  defense,  it  was  alwayi  this  theme  they 
emphasized:  the  corruption  of  military  purpose 

by  procurement. 

--James  Fallows,  National  Defense 


The  EA  Approach  toward  Requirements  Definition 


The  Need 

Paper  studies  and  laboratory  experiments 

will  no  longer  substitute  for  a  "hands-on," 

adaptive,  iterative  requirements  definition  process 

2 

in  acquiring  .actical  C  systems. 

The  frustrated  operational  commanders 
(users)  who  have  had  to  live  with  greaseboards , 
acetate,  and  obsolete  systems  in  their  tactical 
command  centers  are  seeing  that  affordable, 
flexible,  adaptive,  and  supportive  systems  can  be 
rapidly  acquired  to  meet  today's  operational  needs. 
Experience  within  the  DNA,  Army,  and  Marine  Corps 
strongly  indicates  that  EA  strategies  are  paying 


off;  they  have  gained  steady  support  among  users 
despite  attempts  from  the  formal  "acquisition 
communities"  to  disparage  their  successes. 

EA  is  a  viable  acquisition  strategy.  An 
evolutionary  approach  is  warranted  in  the 

2 

development  and  acquisition  of  a  force  level  C 

capability  and  in  the  definition  of  architectures 

2 

within  which  the  Air  Force's  tactical  C  must 
evolve . 

1.  Information  systems  technology  is  changing 
at  a  staggering  rate. 

2.  Command  and  control  systems  are  unique. 

2 

3.  Today's  and  tomorrow's  C  systems  must 

fully  interface  with  a  myriad  ,  of  other 

systems  supporting  the  commander  (one  only 

2 

has  to  read  the  TAF  C  Improvements 
Developers'  Guide) . 

3 

4.  Air  Force  and  joint  tactical  C  archi¬ 
tectures  are  not  well-defined. 

5.  The  "conflict  bandwidth"  has  greatly 
expanded,  and  operational  commanders  must 
have  flexible  systems  that  support  their 
shifting  operational  needs--now. 

Modern  information  systems  must  do  more 
with  less  manpower,  and  remain  affordable. 


6. 


The  Flexibility  to  Implement  EA 

EA  is  generally  supported  by  senior 
military  leaders  who  have  had  experience  in 
system  acquisition.  The  emerging  command  and 
control  managers,  the  senior  officers  who,  in  their 
younger  days,  personally  experienced  acquisition 
horror  stories  like  TACC  AUTO,  are  beginning  to  seek 
answers  to  today's  C"  problems  with  today's 
technology. 

DoD  guidance  provides  the  Services  the 
direction  they  need  to  establish  EA  policy  and 
guidelines.  AFISA  directs  EA  as  a  "preferred 
strategy."  Direction  on  EA  from  the  Joint  Logistics 
Commanders  is  expected  in  early  1986. 

The  Strategy 

The  first  recommendation  in  this  report  is 

that  the  TAG  adopt  EA  as  a  deliberate  strategy  in 

the  development  and  acquisition  of  a  future  force 
2 

level  C  system.  It  is  anticipated  that  the  spate 
of  insurmountable  problems  foreseen  by  the  "business 
as  usual"  community  in  adopting  such  a  strategy  will 
quickly  disappear  when  General  Russ,  Commander  of 
Tactical  Air  Command,  directs  this  initiati’^e. 

"Spoofing  the  system"  (Chapter  II)  is  a  lie 
to  the  Air  Force,  DoD,  Congress,  and  the  taxpayer. 
Establishing  firm,  specific  requirements  for  the 
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entire  life  of  a  C  system  is  a  way  of  Cl)  receiving 
funding,  and  (2)  ensuring  that  funding  is  retained 
when  the  system  is  stacked  against  other  systems  for 
funding.  It  is  planned  deception,  an  attempt  to 
squeeze  an  evolutionary  approach  into  a  system  that, 
as  Mr.  0’ Donohue  has  stated,  knows  only  one  way  of 
doing  things:  the  traditional,  serial,  formal  way.^ 
TAG  has  the  flexibility  to  adopt  EA,  and  should 
exercise  this  flexibility  in  meeting  its  near  term 
and  future  operational  needs. 

The  basic  strategy  should  be  to: 

1.  Establish  a  management  structure  to 
champion  an  EA  strategy. 

2.  Establish  liaison  with  ADEA,  the  TCO 

X 

Development  Office,  17th  AF,  the  JTC  A,  and 
supporting/participating  organizations . 

3.  Redefine  the  relationships  among  users, 
developers  and  testers. 

4.  Describe  in  general  functional  terms  the 
overall  system  requirement;  use  a  "software 
first"  perspective. 

5.  Conduct  a  "hands-on"  test  bed  based 
Requirements  Definition  Study  Period 
CRDSP). 


6.  Begin  design  of  the  architecture  that  al¬ 
lows  system  growth  and  incremental 
fielding. 

7.  Define  in  detail,  fund,  develop,  user-test, 
and  field,  and  user-test  an  operational 
core  system. 

8.  "Build  a  little,  field  a  little,  test  a 
lot." 

9.  Above  all,  sbaurt  small. 

A  test  bed  system  (an  RRDC)  must  be 
established  quickly  and  affordably,  and  the  exploit¬ 
ation  of  the  evolving  test  bed  systems  already  in 
use  is  the  key  to  this. 

The  Marine  Corps  estimated  that  the  cost  to 
develop  software  functionally  equivalent  to  that  of 

SPADS  and  DCCS  would  be  over  $6  million  (in  1984). 

2 

Development  would  require  several  years. 

Readiness  and  Sustainability 

Readiness 

JCS  Pub  6,  Volume  II  is  the  document  that 
governs  the  combat  readiness  status  reporting  from 
the  operational  units  to  the  Joint  Chiefs  of  Staff. 
This  document,  and  command  level  regulations, 
specify  the  way  wartime  readiness  is  quantified. 


The  pivotal  readiness  rating  of  a  UNITREP 
(Unit  Status  and  Identity  Report)  reportable  unit  is 
its  C-Rating,  or  combat  readiness  rating.  The 
overall  C-Rating  of  a  unit  is  derived  from  the 
individual  ratings  of  constituent  areas  (e.g., 
designated  equipment  readiness,  contingency  spares 
status,  training  status),  plus  a  commander's  overall 
(and  pre-eminent)  rating.  The  Designed  Operational 
Capability  (DOC)  statement  is  the  basic  list  of 
systems  against  which  a  unit's  combat -ready  status 
is  rated.  Items  on  the  507th  Tactical  Air  Control 
Wing's  DOC  might  include,  for  example,  OV-10  Bronco 
forward  air  controller  aircraft  or  AN/TRC-97A 
tactical  microwave  radios. 

CAFMS  has  never  achieved  Initial 

Operational  Capability  (IOC),  so  it  is  not  included 

2 

on  the  DOC.  As  the  AFFOR  commander's  force  level  C 
system,  C.^FMS'  present  status  could  be  said  to  have 
seriously  degraded  combat  readiness  of  both  9th  AF 
and  12th  AF  tactical  forces.  If  CAFMS  were  on  the 
DOC,  but  it's  not,  this  fact  would  translate  to  a 
conspicuous  statistic.  Readiness  and  sustainability 
are  issues  (surfaced  in  part  by  events  such  as  the 
Iran  rescue  mission  in  1980)  that  have  received  not 
only  bad  press  but  the  SECDEF's  and  the  JCS's 
unambiguous  concern. 


As  bad  as  CAFMS  is ,  TAGS  personnel  have 
gotten  used  to  it  over  several  years  of  exercises. 


CAFMS  does  provide  an  automated  assist  in  ATO 
preparation,  and  this  has  shaved  several  hours  off 
of  the  manual  process  and  has  indisputably  improved 
accuracy.  Returning  to  a  purely  manual  system  would 
result  in  even  worse  chaos,  especially  in  a 
non-exercise  scenario. 

Tactical  air  forces  must,  in  1985,  be 
prepared  to  fight  and  win  operations  that  CAFMS 
could  not  begin  to  support.  Lieutenant  General 
Cunningham,  Commander,  Twelfth  Air  Force  stated  in 
August  1985: 


Third  World  contingencies  have  and  will  continue 
to  arise  where  Air  Force  forces  have  been 
committed  without  the  benefit  of  an  established 
information  infrastructure  or  the  lead  time 
needed  to  introduce  a  full  Tactical  Air  Control 
System  and  its  complete  command  and  control 
elements,  i.e.,  the  TACCS  (Operations)  and  TIS 
(Intelligence)  squadron^,  and  a  supporting 
communications  squadron. 


Sustainability 

What  happens  if,  next  week,  a  short-notice 
contingency  operation  necessitates  the  deployment  of 
CENTAF  or  USAFSO  forces  and  a  viable  command  and 
control  center  operation?  They  will  undoubtedly  do 
the  very  best  with  the  resources  they  have 
available,  as  professionals  do.  If  the  situation 


involves  the  12th  AF,  there  is  practically  nothing 
with  which  to  work.  The  9th  AF  would  probably 
deploy  its  CROMEMCOs  and  other  CENTAF/personally 
acquired  hardware  and  software,  unsustainable  as  it 
might  be.  One  staff  officer  expressed  that  if 
Lieutenant  General  Kirk,  COMUSCENTAF,  had  to  assign 
a  dedicated  plane  to  fly  ATOs  to  his  subordinate 
wings ,  he  would. 

It  would  seem  that  if  the  efficient, 
accurate,  and  timely  generation  and  distribution  of 
the  commander's  ATO  prevented  one  pilot  and  weapon 
systems  officer,  and  their  F-4E,  from  being  "hosed" 
by  anti-aircraft  fire  or  from  missing  a  refueling 
rendezvous,  then  the  command  and  control  system 
would  quickly  pay  for  itself. 

Interoperability  through  Joint  Architecture 

The  bottom  line  in  interoperability  decisions  is 
to  determine  how  much  interoperability  is 
required  and  what  resources  should  be  used  to 
obtain  that  degree  of  reliability. 

The  above  statement  was  made  by  Lt  Gen  C. 
E.  McKnight ,  USA,  the  Director  for  Command,  Control, 
and  Communications,  Organization  of  the  Joint  Chiefs 

4 

of  Staff.  The  agency  tasked  with  ensuring 
interoperability,  the  JTC^A,  has  begun  the  study  of 


present  architectures  in  the  hope  of  establishing  a 
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baseline  generic  tactical  architecture.  The 

emphasis  at  this  point  is  to  identify  joint 

interface  points  and  the  interoperability  require- 

5  3 

ments  at  each  of  these  points.  At  present  JTC  A  is 

working  from  documents  such  as  the  TAFIIS  Master 

Plan  (see  Chapter  IV). 

Through  the  experience  gained  with  SPADS  at 

the  corps  level,  and  DCCS  at  the  division  level,  the 

2 

Army  has  guided  the  evolution  of  its  tactical  C 

requirements  and  its  force  level  control 

architectures  from  the  company  through  the  corps 

level.  The  Marine  Corps  will  be  able  to  better 

2 

define  its  MAGTF  C  requirements  through  the  TCO 
Test  Bed.  The  basic  logic: 

2 

1.  To  adopt  an  evolutionary  approach  toward  C 

requirements  definition. 

2 

2.  To  define  C  system  architecture  from  user 
requirements . 

2 

TAC  can  field  a  C  system  that  can  meet 
near  term  user  needs  and  at  the  same  time  begin 
defining  its  TACS  architecture  by  following  the 
above  (admittedly  incomplete)  logic. 

If  CINC  (i.e..  Unified  and  Specified 
Command)  architecture  is  considered  to  most 

3 

influence  the  JTC  A's  joint  architecture  development 


efforts,  and  if  evolutionary  approaches  are  being 

taken  in  the  design  of  service  component 

architectures,  then  it  would  stand  to  reason  that 

the  evolutionary  development  of  a  Unified 
2 

commander's  C  requirements  would  shed  a  great  deal 

of  light  on  solving  the  interoperability  problem. 

In  Chapter  VI  it  was  recommended  that  compatibility 

and  interoperability  be  aggressively  exercised, 

tested,  and  evaluated  through  "hands-on" 

experiments,  exploiting  the  proven  capabilities  of 

2 

SPADS  and  DCCS  based  C  systems.  As  mentioned  in 

3 

Chapter  I,  the  JTC  A  could  benefit  from  such  an 
approach  as  well  as  the  users.  There  should  be  no 

3 

problem  getting  enthusiastic  planners  from  JTC  A  to 
study  and  assist  such  a  user-driven  initiative. 
This  initiative  would  be  a  first  Cand, 
therefore , encounter  resistance),  but  results  would 
surely  be  shown  quickly. 

A  Few  Variables 

There  are  few  precedences  for  EA  within  the 

Air  Force;  there  is  no  precedent  for  a  deliberate  EA 

2 

strategy  toward  the  fielding  of  T.^CS  C  systems.  A 
few  variables : 

1.  A  very  recent  change  in  TAF  senior  leader- 
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2.  A  force  level  automated  assist  that  does 
not  adequately  meet  present  or  projected  require¬ 
ments  and  has  degraded  present  readiness. 

3.  Establishment  of  Air  Force  information 
systems  doctrine  and  long-range  planning. 

2 

4.  The  flexibility  to  adopt  EA  for  C  systems. 

5.  The  opportunity  to  actually  plan,  user- 
test,  and  evaluate  compatibility  and  interopera¬ 
bility  in  the  near  term. 

6.  The  opportunity  to  be  innovative  and 
realize  the  results  of  such  innovation  in  both 
warfighting  capability  and  taxpayer  savings. 

The  1984  Air  Force  merger  of  ADP  and 
communications  into  information  systems  has  blurred 
the  distinction  between  the  two  previously  very 
separate  activities.  This  merger  set  the  groundwork 
for  information  systems  architectural  policy. 

No  events  will  shape  the  future  of  tactical 

2 

C  systems  more  than  the  marriage  of  EA  into 
developing  architectures  and  the  leadership  driving 
it. 
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APPENDIX  A 
LIST  OF  ACRONYMS 


LIST  OF  ACRONYMS 


AADCOM 

Army  Air  Defense  Command 

AAFCE 

Allied  Air  Forces  Central  Europe 

ABCCC 

Airborne  Battlefield  Command  Control 
Center 

ACCS 

Airborne  Command  and  Control  Squadron 

ADEA 

Army  Development  and  Employment  Agency 

AF 

Air  Force 

AFAA 

Air  Force  Audit  Agency 

AFCC 

Air  Force  Communications  Command 

AFCEA 

Armed  Forces  Communications  and 
Electronics  Association 

AFFOR 

Air  Force  Forces 

AFISA 

Air  Force  Information  Systems 
Architecture 

AFLC 

Air  Force  Logistics  Command 

AFMAG 

Air  Force  Management  -Analysis  Group 

AFOTEC 

Air  Force  Operational  Test  and 
Evaluation  Center 

AFSC 

Air  Force  Systems  Command 

AFSC 

Air  Force  Specialty  Code 

AG  OS 

Air-Ground  Operations  School 

AI 

Artificial  Intelligence 

AJ 

Ant i -Jam 

ASAS 

All  Source  -Analysis  System 
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LIST  OF  ACRONYMS 
(continued) 


ATAF 

Allied  Tactical  Air  Force 

ASOC 

Air  Support  Operations  Center 

ATO 

Air  Tasking  Order 

ATOC 

Allied  Tactical  Operations  Center 

ATTB 

Advanced  Technology  Test  Bed 

AUTODIN 

Automatic  Digital  Network 

AWACS 

Airborne  Warning  and  Control  System 

BCE 

BPI 

BPS 


C^IS 

CAFMS 

CAI 

C*W-G 

CENTAG 

CG 

CGS 


Battlefield  Coordination  Element 
Bits  per  Inch 
Bits  per  Second 

Command  and  Control 

Command  and  Control  and  Communications 

Command,  Control,  Communications,  and 
Intelligence 

Command,  Control,  Communications, 
Computer  and  Intelligence  Systems 

Computer  Assisted  Force  Management 
System 

Computer  Assisted  Instruction 
Computer-Assisted  Message  Generator 
Central  Army  Group 
Commanding  General 
Communications  Gateway  Station 
Commander  in  Chief 


CINC 
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LIST  OF  ACRONYMS 
(continued) 


CIU 

Communications  Interface  Unit 

CLiP 

Communications  Link  Processor 

COMUSCENTAF 

Commander  United  States  Central 

Command  Air  Forces 

CPU 

Central  Processing  Unit 

CPX 

Command  Post  Exercise 

CRC 

Control  and  Reporting  Center 

CTOC 

Corps  Tactical  Operations 

Center 

DAC 

Defense  Acquisition  Circular 

DARPA 

Defense  Advanced  Research  Projects 
Agency 

DAViD 

Data  Automated  Video  Display  System 

Decs 

Distributed  Command  and  Control  System 

DCIU 

DCCS  Communications  Interface  Unit 

DC/SR 

Display  and  Control/Storage  and 
Retrieval  system 

DNA 

Defense  Nuclear  Agency 

DOC 

Designed  Operational  Capability 

DoD 

Department  of  Defense 

DoDD 

Department  of  Defense  Directive 

DOS 

Disk  Operating  System 

DPO 

Development  Project  Officer 

DSB 

Defense  Science  Board 

DSMC 

Defense  Systems  Management  College 

DSU 

Direct  Support  Unit 

EA 

Evolutionary  Acquisition 

EIFEL 

European  Command  and  Control  System 

LIST  OF  ACRONYMS 
Ccontinued) 
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FLINT 

Electronics  Intelligence 

ENSCE 

Enemy  Situation  and  Correlation 
Element 

EPROM 

Erasable  Programmable  Read  Only 
Memory 

ESC 

Electronic  Security  Command 

FM 

Frequency  Modulation 

FP 

Force  Planning 

FRG 

Federal  Republic  of  Germany 

FSSG 

Force  Service  Support  Group 

FY 

Fiscal  Year 

GPE 

Government  Furnished  Equipment 

GPIB 

General  Purpose  Interface  Bus 

HF 

High  Frequency 

HMMh^ 

High  Mobility,  Multi-Purpose  Wheeled 
Vehicle 

HQ 

Headquarters 

HTLD 

High  Technology  Light  Division 

HUMINT 

Human  Intelligence 

I  CP 

Integrated  Command  Post 

ID 

Infantry  Division 

lEW 

Intelligence  and  Electronic  Warfare 

IP 

Internet  Protocol 

IR 

Infrared 
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LIST  OF  ACRONYMS 
(continued) 


ISB 

Independent  Sideband 

ISSG 

Information  Systems  Support  Group 

JAMPS 

JINTACCS  Automated  Message  Preparation 
System 

JANAP 

Joint  Army,  Navy,  Air  Force 

Publication 

JCS 

Joint  Chiefs  of  Staff 

JINTACCS 

Joint  Interoperability  of  Tactical 
Command  and  Control  Systems 

JTC^^ 

Joint  Tactical  Command,  Control,  and 
Communications  Agency 

KBPS 

Kilobits  per  Second 

KTACS 

Korean  Tactical  Air  Control  System 

L ANT COM 

Atlantic  Command 

LAN 

Local  Area  Network 

LENSCE 

Limited  Enemy  Situation  and 

Correlation  Element 

LPM 

Lines  per  Minute 

LSD 

Large  Screen  Display 

MAC 

Military  Airlift  Command 

MAF 

Marine  Amphibious  Force 

MAGTF 

Marine  Air-Ground  Task  Force 

MB 

Megabyte 

MCDEC 

Marine  Corps  Development  and 

Education  Command 
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LIST  OF  ACRONYMS 
(continued) 


MCE 

Modular  Control  Equipment 

MCS 

Maneuver  Control  System 

MIFASS 

Marine  Integrated  Fire  and  Air 
Support  System 

MIJI 

Meaconing,  Intrusion,  Jamming, 
and  Interference 

MILSPEC 

Military  Specification 

MISCAP 

Mission  Capability  Statement 

MPC 

Message  Processing  Center 

MSS 

Mass  Storage  Station 

NATO 

North  Atlantic  Treaty  Organization 

NAVE LEX 

Naval  Electronic  Systems  Command 

NCP 

Network  Control  Processor 

NDI 

Nondevelopmental  Item 

NOFORN 

Not  Releasable  to  Foreign  Nationals 

NORAD 

North  American  Aerospace  Defense 
Command 

OSM 

Operations  and  Maintenance 

OS 

Operating  System 

P^I 

Pre-planned  Product  Improvement 

PACAF 

Pacific  Air  Forces 

PC 

Personal  Computer 

PDP 

Program  Decision  Package 

PE 

Perkin-Elmer 

PM 

Program  Manager 
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LIST  OF  ACRONYMS 
(continued) 


PMD 

Program  Management  Directive 

PMO 

Program  Management  Office 

PRO 

Program  Review  Organization 

R.^M 

Random  Access  Memory 

RDJTF 

Rapid  Deployment  Joint  Task  Force 

RDSP 

Requirements  Definition  Study  Period 

ROC 

Required  Operational  Capability 

ROKAF 

Republic  of  Korea  Air  Force 

ROM 

Read  Only  Memory 

RRDC 

Rapid  Requirements  Definition 
Capability 

SAT COM 

Satellite  Communications 

SCI 

Single  Channel  Interface 

SCO 

Science  Technology  Objective 

SDS 

Staff  Duty  Station 

SHF 

Super  High  Frequency 

SIGINT 

Signals  Intelligence 

SIU 

Serial  Interface  Unit 

SOC 

Sector  Operations  Center 

SON 

Statement  of  Need 

SOS 

Shared  Output  Station 

SPADS 

Staff  Planning  and  Decision  Support 
System 

SSF 

Software  Support  Facility 

SWA 

Southwest  Asia 
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TAG 

TACC 

TACCS 

TACTICS 

TAGS 

TADIL 

TAP 

TAFIG 

TAFIIS 

TASS 

TC^  -  21 

TCO 

TCP 


TCP 

TCS(T) 

TEP 

TIS 

TOC 

TRI-TAC 

UDDAS 


LIST  OF  ACRONYMS 
(continued) 

Tactical  Air  Command 

Tactical  Air  Control  Center 

Tactical  Air  Control  Center  Squadron 

Tactical  Information  Control  System 

Tactical  Air  Control  System 

Tactical  Digital  Information  Link 

Tactical  Air  Forces 

Tactical  Air  Forces  Interoperability 
Group 

Tactical  Air  Forces  Integrated 
Information  System 

Tactical  Switched  System 

21st  Centurv  Tactical  Command  and 
Control  Architecture  Working  Group 

Tactical  Combat  Operations 

Transmission  Control  Protocol 

Tactical  Computer  Processor 

Tactical  Control  Squadron  (Test) 

Tactical  ELINT  Processor 

Tactical  Intelligence  Squadron 

Tactical  Operations  Center 

Joint  Tactical  Communications 
Program 

USAREUR  Distributed  Decision  Aid 
System 

Uninterruptable  Power  Supply 


UPS 
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LIST  OF  ACRONYMS 
(continued) 


USA 

United  States  Army 

USAF 

United  States  Air  Force 

USAFE 

United  States  Air  Forces  in  Europe 

USAFSO 

United  States  Air  Forces  Southern 
Command 

USAFTAWC 

United  States  Air  Force  Tactical  Air 
Warfare  Center 

USAREUR 

United  States  Army  Europe 

USMARCENT 

United  States  Marine  Corps  Central 
Command 

USCENTCOM 

United  States  Central  Command 

USMC 

Untied  States  Marine  Corps 

USN 

United  States  Navy 

UTC 

Unit  Type  Code 

VP 

Video  Package 

woe 

Wing  Operations  Center 

WINTEL 

With  Intelligence  Information 

WS 

Workstation 

WSO 

Weapon  Systems  Officer 

GLOSSARY 


Air  Force  Information  System  Architecture.  A 
conceptual  framework  for  all  Air  Force 
information  system  elements  and  interrelation¬ 
ships;  the  hierarchy  of  technical,  functional 
and  command  information  system  architectures 
within  the  Air  Force.  (AFISA) 

Airborne  Battlefield  Command  and  Control  Center 

(ABCCC) .  The  ABCCC  is  an  airborne  command  and 
control  element  of  the  TACS  that  provides 
management  of  tactical  forces  operating  beyond 
the  normal  communication  coverage  of  ground  TACS 
elements.  The  mobility  and  communications 
advantages  inherent  in  this  platform  enable  it 
to  stay  abreast  of  the  current  ground  and  air 
situation  within  its  assigned  area  of  responsi¬ 
bility.  This  assures  continuity  of  operation  in 
the  event  elements  of  the  TACS  are  disabled  or 
not  yet  deployed.  The  ABCCC  system,  with  its 
trained  battle  staff,  is  able  to  perform  limited 
roles  for:  Crisis  Management,  Special/Contin¬ 
gency  Operations,  TACC  Combat  Operations,  and 
ASOC  (see  TACR  55-130).  (TACR  55-45) 

Architecture.  The  architecture  of  a  system  relates 
to  its  design,  and  the  way  in  which  the 
component  parts  interrelate.  It  refers  to  the 
logical  structure  of  a  system,  rather  than  the 
specification  details  of  the  individual 
components  used  to  construct  the  system. 

Architecture  as  used  in  the  Air  Force 
Information  Systems  Architecture  is  not  in  the 
traditional  Air  Force  sense.  It  is  not  simply  a 
programmatic  document.  An  architecture 
describes  the  current  situation  (point  A)  and 
the  target  environment  architecture  (point  B) . 
It  then  describes  the  approach  required  to  get 
from  point  A  to  point  B  in  terms  of  technologies 
and  capabilities  which  need  to  be  exploited  by 
all  programs.  (AFISA  Vol.  II  draft) 

Area  of  Responsibility.  A  defined  area  of  land  in 
which  responsibility  is  specifically  assigned  to 
a  commander  of  the  area  for  the  development  and 
maintenance  of  installations,  control  of 


movement,  and  conduct  of  tactical  operations 
involving  troops  under  his  control  along  with 
parallel  authority  to  exercise  these  functions. 
CJCS  Pub  1) 

Army-Air  Force  Center  for  Low  Intensity  Conflict. 

Planned  in  1985  as  an  Air  Force-only  initiative, 
the  center  will  be  established  as  a  joint  Army- 
Air  Force  center  in  early  1986.  Headquartered 
at  Langley  AFB,  VA,  the  organization  will  be 
manned  by  30  specialists  who  will  study  low- 
intensity  conflict  and  identify  resources  needed 
to  improve  low- intensity  conflict  capabilities. 
The  Navy  is  expected  to  join  the  center  in  1987. 
The  first  commander  of  the  center  will  be  Col 
Frederick  C.  Bosse,  who  will  move  from  his 
position  of  director  of  operations  of  the  5D7'i.h 
TAIRCW  C9th  AF),  Shaw  AFB,  SC. 

Combined.  Between  two  or  more  forces  or  agencies  of 
two  or  more  allies.  (When  all  allies  or 
Services  are  not  involved,  the  participating 
nations  and  Services  shall  be  identified,  e.g., 
combined  Navies.)  See  also  joint.  (JCS  Pub  1) 

Command  and  Control..  The  exercise  of  authority  and 
direction  by  a  properly  designated  commander 
over  assigned  forces  in  the  accomplishment  of 
the  mission. 

Command  and  Control  Systems.  1.  Those  systems  that 
augment  the  decision-making  and  decision-execut¬ 
ing  processes  of  operational  commanders  and 
their  staffs.  The  central,  essential  ingredient 
in  any  command  and  control  system  is  the 
commander  or  decision  maker  himself.  CAFCEA/ 
This  Report)  2.  Those  facilities,  equipment, 
communications,  procedures,  and  personnel 
essential  to  a  commander  for  planning, 
directing,  and  controlling  operations  of 
assigned  forces  pursuant  to  the  missions 
assigned.  (JCS  Pub  1) 

Command  Architecture.  A  framework  or  formulation  of 
mission-oriented  information  system  elements, 
both  functional  and  technical,  which 
interrelate  to  support  a  command’s  war-fighting 
capability  and  other,  command  unique  missions; 
these  apply  the  system  design  guidance  of 
technical  architectures  and  the  information  flow 
guidance  of  functional  architectures  (logistics, 
command  and  control,  etc.)  to  the  command 
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mission  requirements.  Major  Commands,  Separate 
Operating  Agencies  and  Direct  Reporting  Units 
create  Command  architectures  and  use  them  in 
program  and  project  evaluations.  (AFISA) 

Command  Center.  A  facility  from  which  a  commander 
and  his  representatives  direct  operations  and 
control  forces.  It  is  organized  to  gather, 
process,  analyze,  display,  and  disseminate 
planning  and  operational  data  and  perform  other 
related  tasks.  (JCS  Pub  1) 

Command  Post  Exercise  (CPX).  An  exercise  in  which 
the  forces  are  simulated,  involving  the 
commander,  his  staff,  and  communications  within 
and  between  headquarters.  (JCS  Pub  1) 

Compatibility.  Systems  for  tactical  command  and 

control,  and  communications  are  compatible  with 
one  another  when  necessary  information  can  be 
exchanged  at  appropriate  levels  of  command 
directly  and  in  usable  form.  Equipments  are 
compatible  with  one  another  if  signals  can  be 
exchanged  between  them  and  if  the  equipments  or 
systems  being  interconnected  possess  comparable 
performance  characteristics  including 
suppression  of  undesired  radiation.  (TC^-21) 

Connectivity.  That  linkage  of  (tele)  communication 
paths  which  organizes  an  assembly  of  resources 
and  procedures,  united  and  regulated  by  inter¬ 
action  or  interdependence,  ^o  accomplish  a  set 
of  specific  functions.  (TC‘^-21) 

CONSTANT  WATCH.  The  PACAF  CONSTANT  WATCH  program  is 
a  multiphased  effort  to  provide  selected 
upgrades  to  the  Korean  Tactical  Air  Control 
System  (KTACS) ,  supporting  combined  Republic  of 
K^rea  Air  Force  (ROKAF)/USAF  operations.  (TAF 
L  Improvements  Developers'  Guide) 

Defense  Science  Board  (DSB).  The  DSB  is  the  senior 
independent  advisory  body  of  the  Department  of 
Defense.  It  was  established  in  1956  and 
undertakes  tasks  of  high  personal  interest  to 
the  Secretary  of  Defense,  the  Deputy  Secretary 
of  Defense,  the  Under  Secretary  of  Defense  for 
Research  and  Engineering  or  the  Chairman  of  the 
Joint  Chiefs  of  Staff.  (Charles  A.  Fowler, 
Chairman  of  the  DSB) 
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EIFEL  (European  Command  and  Control  System).  EIFEL, 
developed  by  the  Federal  Republic  of  Germany  and 
acquired  by  iinilateral  agreement,  provides  a 
similar  capability  to  CAFMS  to  the  principally 
U.S.  manned  and  equipped  Allied  Tactical  Air 
Operations  Center  at  Sembach  Air  Base,  Germany. 
The  functions  performed  by  EIFEL  are  similar  to 
those  performed  by  CAFMS,  but  they  are 
implemented  in  a  slightly  different  way.  EIFEL 
is  already  operational  at  the  German  Allied 
Tactical  Operations  Centers  at  Kalkar, 
Messtetten,  and  the  U.S.  manned  and  equipped 
ATOC  at  Sembach,  Germany.  (TAC  C^  Improvements 
Developers'  Guide) 

Evolutionary  Acquisition.  A  system  acquisition 

strategy  in  which  a  basic  capability  is  fielded 
quickly  to  satisfy  a  general  statement  of  the 
requirement.  Subsequent  increments  are  acquired 
based  on  end-user  feedback  from  acceptance 
testing  and  operational  use  of  each  increment 
fielded.  (AFISA) 

Functional  Architecture.  A  framework  or  description 
of  support  functions  (for  example,  services, 
capabilities,  and  interfaces  to  them)  which 
interrelate  to  satisfy  particular  needs  for 
information,  where  and  when  needed.  Major 
functional  areas  (Plans  and  Operations, 
Logistics,  Comptroller)  create  these 
architectures  using  technical  guidance  supplied 
by  the  Air  Force  Information  Systems 
Architecture.  (AFISA) 

Ground  Attack  Control  Center  (GACC) .  The  GACC  is  a 
software  capability  that  decentralizes  the 
attack  of  time-sensitive  ground  targets.  GACC  is 
modeled  on  the  existing  air  defense  Control  and 
Reporting  Center  (CRC)  structure.  GACC  will 
receive  ground  target  information  on  mobile 
targets  (moving  and  stationary)  using  existing/ 
programmed  systems.  Weapons  will  be  matched  to 
targets  at  the  G.ACC  according  to  established 
guidance  and  priorities.  The  G.^CC  will  provide 
the  latest  target  data,  threat  warning,  and 
other  mission  essential  information  to  attack 
aircraft.  Each  operations  module  of  the  MCE  is 
planned  to  be  able  to  perform  CRC  or  GACC 
functions.  (TAFIG  Smart  Book) 


Implementing  Command.  1.  The  command  responsible 

for  exercising  overall  management  of  an  approved 
program  for  engineering,  installing,  and  testing 
the  facilities  or  equipment  necessary  to  fulfill 
a  requirement.  (APR  700-3)  2.  The  command  or 

agency  designated  by  Headquarters,  United  States 
Air  Force  to  manage  an  acquisition  program. 
(APR  800-2} 

Information  System.  The  totality  of  resources 
devoted  to  handling  information  needed  by  a 
specified  end-user  community.  CAFISA) 

Interoperability.  1.  The  ability  of  systems, 

units,  or  forces  to  provide  services  to  and 
accept  services  from  other  systems,  units,  or 
forces  and  to  use  the  services  so  exchanged  to 
enable  them  to  operate  effectively  together. 

2.  The  condition  achieved  among  communications- 
electronics  systems  or  items  of  communications - 
electronics  equipment  when  information  or 
services  can  be  exchanged  directly  and 
satisfactorily  between  them  and/or  their  users. 
The  degree  of  interoperability  should  be  defined 
when  referring  to  specific  cases.  (JCS  Pub  1) 

Joint.  Connotes  activities,  operations,  organiza¬ 
tions,  etc.,  in  which  elements  of  more  than  one 
Service  of  the  same  nation  participate.  When 
all  Services  are  not  involved,  the  participating 
Services  shall  be  identified;  e.g.,  joint  Army- 
Navy.  See  also  combined.  (JCS  Pub  1) 

Military  Capability.  The  ability  to  achieve  a 
specified  wartime  objective  (win  a  war  or 
battle,  destroy  a  target  set).  It  includes  four 
major  components:  force  structure, 

modernization,  readiness,  and  sustainability. 
(JCS  Pub  1) 

Mobility.  A  quality  or  capability  of  military  forces 
that  permits  them  to  move  from  place  to  place 
while  retaining  the  ability  to  fulfill  their 
primary  mission.  (JCS  Pub  1) 

Modular  Control  Equipment  (MCE).  The  MCE  program 
consists  of  two  key  efforts  to  improve  the 
ground  Tactical  Air  Control  System  (T.\CS) . 
First,  MCE  will  replace  obsolete  CRC  command  and 
control  operations  centers.  Since  each  module 
has  an  inherent  message  processing  capability, 
MCE  will  replace  the  MPC.  Second,  the  MCE 
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program  will  provide  a  hardware  baseline  for  the 
GACC,  an  additional  operational  function  that 
will  permit  display  at  the  CRC  level  of  time- 
sensitive  ground  targets  (i.e.,  tank/troop 
concentrations,  threat  emitters,  high-value 
point  targets,  etc.)  in  the  enemy  second 
echelon.  GACC  will  receive  and  display  ground 
targets  based  on  sensor  data  from  the  Joint 
Surveillance  and  Target  Attack  Radar  System 
(Joint  STARS) ,  Precision  Location  Strike  System 
(PLSS) ,  and  Advanced  Synthetic  Aperture  Radar 
System  (ASARS).  GACC  controllers  will  use  this 
information  to  provide  in-flight  target/threat 
updates  to  attack  aircrews.  Presently,  GACC  is 
planned  as  a  software  change  to  the  basic  MCE 
module  to  provide  a  display  2  capability  for 
ground  track  data.  (TAP  C^  Improvements 
Developers '  Guide) 

Operational  Suitability.  The  degree  to  which  a 

system  can  be  satisfactorily  placed  in  field 
use,  with  consideration  being  given  to 
availability,  compatibility,  transportability, 
interoperability,  reliability,  wartime  usage 
rates,  maintainability,  safety,  human  factors, 
manpower  supportability ,  logistic 
supportability ,  and  training  requirements.  (DoD 
Directive  5000,1) 

Participating  Command.  Program  Management  Directive 
(PMD)  designated  command  or  agency  that  provides 
support  and  takes  part  in  carrying  out  tasks  the 
PMD  and  Program  Management  Plan.  (APR  57-1) 

Program  Management  Directive  (PMD).  The  official 
Headquarters  United  States  Air  Porce  (HQ  USAP) 
management  directive  used  to  provide  direction 
to  the  implementing  and  participating  commands 
and  to  satisfy  documentation  requirements.  It 
is  used  throughout  the  acquisition  cycle  to 
state  requirements  and  request  studies  and  to 
initiate,  approve,  change,  transition,  modify, 
or  terminate  programs.  The  content  of  the  PMD, 
including  the  required  HQ  USAP  review  and 
approval  actions,  is  tailored  to  the  needs  of 
each  individual  program.  (APR  800-2) 

Readiness.  The  ability  of  forces,  units,  weapon 

systems,  or  equipment  to  deliver  the  outputs  for 
which  they  were  designed  (includes  the  ability 
to  deploy  and  employ  without  unacceptable 
delays).  (JCS  Pub  1) 
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Reliability.  The  ability  of  an  item  to  perform  a 
required  function  under  stated  conditions  for  a 
specified  period  of  time.  CJCS  Pub  1) 


SIGMA  STAR.  A  graphical  representation  of  an 

integrated  structure  of  five  "functional  areas": 
maneuver  control,  fire  support,  air  defense 
artillery,  intelligence/electronic  warfare,  and 
combat  service  support. 


mm 

iKijj.via 

COMTmM. 

CONTROL  1 

The  SIGMA  STAR 

The  overall  commander  of  each  echelon  Ce*g., 
brigade,  division)  is  able  to  utilize 
information  from  each  of  the  functional  areas, 
from  any  part  of  the  battlefield,  for  force 
level  control. 

Supportability .  The  ability  of  a  system  to  be 

logistically  supportable.  Requirements  must  be 
satisfied  within  established  time  frames 
required  for  mission  effectiveness. 
Supportability  is  closely  related  to  reliability 
and  maintainability. 

Survivability.  The  ability  of  a  system  to  continue 
to  perform  essential  functions  in  the  absence  of 
some  of  its  components.  Factors  to  be 
considered  include  hardness,  protectability , 
mobility,  reconstitutability  and  redundancy. 
CTC^-21) 


Sustainability.  The  ability  to  maintain  the 

necessary  level  and  duration  of  combat  activity 
to  achieve  national  objectives.  Sustainability 
is  a  function  of  providing  and  maintaining  those 
levels  of  force,  materiel,  and  consumables 
necessary  to  support  a  military  effort.  (JCS 
Pub  1) 

TAP  (Tactical  Air  Forces).  The  TAP  is  comprised  of 
Tactical  Air  Command  (TAG) ,  the  United  States 
Air  Forces  in  Europe  (USAFE) ,  and  the  Pacific 
Air  Forces  (PACAF). 

Technical  (or  Subsystem)  Architecture.  A  framework 
of  concepts  and  guidance  which  band  a  subject 
area,  or  of  physical  components  (e.g.,  hardware, 
software,  transmission  media)  which  interrelate 
to  perform  a  bounded  subset  of  information 
handling,  both  processing  and  transfer.  (AFISA) 

TEMPEST.  TEMPEST  is  a  short  name  referring  to 

investigations  and  studies  of  compromising 
emanations.  TEMPEST  is  often  used  synonymously 
for  the  term  "compromising  emanations,"  as  in 
TEMPEST  tests,  TEMPEST  inspections,  and  TEMPEST 
certification. 

Test  Bed  (General  Definition).  A  facility  or 

composite  of  resources  used  to  obtain,  verify  or 
provide  qualitative  and/or  quantitative  data  for 
evaluation  of  progress  toward  completing 
development  objectives,  system  performance  or 
operational  capability  and  utility.  (Brig  Gen 
Brown) 

The  test  bed  system  in  this  report  is 
additionally  referred  to  as  a  prototype  and  a 
Rapid  Requirements  Definition  Capability  (see 
Chapter  IV) ,  the  main  purpose  of  which  is  to 
enable  TAG  to  quickly,  intelligently,  and 
accurately  sp&cify  requirements  for  a  "core" 
force  level  C^  system;  develop  a  TACC  system 
concept;  begin  definition  of  TAGS  architecture; 
and  exercise,  test,  and  evaluate  interoperabili¬ 
ty  in  "hands-on"  experiments. 

Transportability.  The  capability  of  material  to  be 
moved  by  towing,  self-propulsion ,  or  carrier  via 
any  means,  such  as  railways,  highways, 
waterways,  pipelines,  oceans,  or  airways.  (JCS 
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TRI-TAC  (Joint  Tactical  Communications)  Program. 
TRI-TAC  is  a  joint  service  tactical 
communications  equipment  program  designed  to 
replace  old  analog  equipment.  TRI-TAC  deals 
with  the  design,  development,  and  acquisition  of 
the  equipment.  It  is  a  family  of  tactical 
communications  systems,  which  includes  the 
following:  message  and  telephone  switches; 

communications  control  facilities;  transmission 
equipment  (tropospheric  scatter  radio) ;  user 
terminals  (teletype,  telephones,  and  facsimile); 
and  communications  security  equipment  (crypto 
devices).  TRI-TAC  will  be  utilized  throughout 
the  TAP.  USAFE  has  priority  within  the  Air 
Force  for  receipt  of  the  first  TRI-TAC 
equipment.  (TAFIG  Smart  Book) 

Unified  Command.  A  command  with  a  broad  continuing 
mission  under  a  single  commander  and  composed  of 
significant  components  of  two  or  more  Services, 
and  which  is  established  and  so  designated  by 
the  President,  through  the  Secretary  of  Defense 
with  the  advice  and  assistance  of  the  Joint 
Chiefs  of  Staff  (JCS);  when  so  authorized  by  the 
JCS,  by  a  commander  of  an  existing  unified 
command  established  by  the  President.  (JCS  Pub 
1) 

U.S.  Central  Command  Air  Forces  (USCENTAF). 

USCENTAF  is  the  Air  Force  component  of  U.S. 
Central  Command  (USCENTCOM) ,  the  unified 
command.  The  Commander,  USCENTAF  is  "dual 
hatted"  as  the  Commander,  Ninth  Air  Force  (9th 
AF)  within  Tactical  Air  Command.  USCENTAF  and 
9th  AF  headquarters  are  located  at  Shaw  Air 
Force  Base,  South  Carolina. 

User  (End-User).  The  individual  or  organization 
having  a  need  for  information  in  order  to 
perform  command,  control,  or  management  of  Air 
Force  resources.  (AFIS.^) 

Vulnerability.  The  characteristics  of  a  system 

cause  it  to  suffer  a  definite  degradation  of 
mission  performance  as  a  result  of  having  been 
subjected  to  a  hostile  environment.  (TC^-21) 

Weapon  System.  A  delivery  vehicle  and  weapon 

combination  including  all  related  equipment, 
materials,  services  and  personnel  required  so 
that  the  system  becomes  self-sufficient  in  its 
intended  operational  environment.  (JCS  Pub  1) 


APPENDIX  C 

EVOLUTIONARY  ACQUISITION  COMPARED  WITH 
PRE-PLANNED  PRODUCT  IMPROVEMENT 


d.  Evolutionary  Acquisition  Compared  with  P  I 

The  Study  Team  found  much  confusion  in 
various  policy  and  field  groups  visited  about  the 
difference  between  "Evolutionary  Acquisition"  CEA) 

3 

and  "Pre-Planned  Product  Improvement"  CP  !)•  Most 
either  considered  them  to  be  quite  similar,  if  not 

3 

identical,  or  EA  merely  to  be  a  sub-set  of  P  I.  The 
Study  Team  found  a  number  of  similarities  and 
differences  between  the  two  approaches.  The 
similarities  are  as  follows: 

(1)  Both  are  incremental  approaches,  where  it 

is  planned  to  implement  regular  upgrades 

from  the  beginning  of  a  program. 

(23  In  both  cases,  initial  and  subsequent 

design  efforts  are  deliberately  approached 

in  such  a  way  that  the  planned  upgradings 

can  be  accomplished  more  easily,  i.e., 

design  is  focused  initially  as  much  on 

changeability  as  on  system  optimization. 

2 

In  the  case  of  C  systems,  this  might  be 
done  by  providing  extra  through-put 
capacity  and/or  memory  and  taking  a  modular 
approach  to  system  design. 


(3)  Both  ordinarily  involve  initially  striving 
for  something  less  than  either  the  system 
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or  technological  states -of -the-art  would  permit, 
particularly  something  less  than  the  most 
far-reaching  states,  or  "revolutionary"  leaps,  would 
permit . 


In  view  of  these  similarities,  one  might 
ask  what  differences  there  are  between  the 

3 

"evolutionary  approach"  and  PI.  In  answer,  several 

2 

possible  differences  might  be  noted  where  C  systems 
are  concerned: 

Cl)  The  evolutionary  approach  usually  is 

adopted  as  a  strategy  because  it  has  to  be, 
i.e.,  because:  (a)  it  is  so  difficult  to 
state  requirements  adequately  at  the 
beginning  of  a  true  C  program,  (b)  such 
requirements  are  expected  to  change 
frequently  over  the  life  of  the  program,  or 
Cc)  users  cannot  specify  acceptability 
criteria  adequately  in  advance  due  to  the 
subjective  nature  of  these  criteria.  This 
leads  to  a  "design-  and-tryout"  approach 
having  to  be  taken  both  to  defining  the 
need  and  to  the  approach  to  satisfying  the 
need.  In  contrast,  the  P^I  strategy  may  be 
adopted  for  any  one  of  a  number  of  reasons , 
even  when  it  doesn't  have  to  be--even,  for 


example,  when  a  requirement  can  be  stated 
adequately  and  its  achievement  can  be 
measured  objectively. 

(2)  An  overall  program  to  which  the 

evolutionary  approach  is  being  taken  may 

involve  little  to  no  advanced  development 

C6.2/6.3A)  o£  any  type:  for  example,  when 

2 

the  user  upgrades  his  C  capability  through 
using  existing  commercial  or  military 
material  to  build  a  "prototype”  of  some 
type.  In  fact,  this  is  the  mode  preferred 
by  policy  (Section  13  of  DoDI  5000.2  of 
March  1980;  Appendix  D  hereto).  In 
contrast,  a  P  I  program  ordinarily  does 
involve  advanced  forms  of 
development--significant  amounts  of  such 
development,  in  fact.  Indeed,  P^I  is  a 
strategy  that  has  come  to  the  fore  in 
recent  times  as  a  means  of  dealing  with 
just  such  uncertain  advances,  because, 
among  other  principal  reasons,  the 
development  period  involved  in  taking  a 
very  large  or  "revolutionary"  jump  towards 
the  limits  of  art,  each  time  a  new  program 
starts,  has  been  taking  so  long  and  been 
so  risky,  that  U.S.  readiness  is  being 
threatened. 


(3)  While  it  is  highly  desirable  that  users  be 

3 

constantly  knowledgeable  about  P  I 
programs --indeed,  play  a  continuous,  if 
reactive  role  in  the  acquisition  of  any  DoD 

3 

system- -the  P  I  approach  per  se  does  not 

require  that  the  user  accept  any 

significant  responsibility  at  any  stage  of 

the  acquisition  cycle.  In  contrast,  strong 

real  user/lead  user  participation  in  and 

influence  over  the  acquisition  is  a  major 

2 

aspect  of  the  EA  of  C  systems,  as 
previously  indicated.  EA  requires  a  larger 
role  and  heavier  continuing  involvement  in 
the  user  in  terms  of: 

-Planning  and  design  initiative  (e.g., 
CAFMSj . 

-Relative  responsibility  for  program 
results . 

-Management  control  of  the  program  as  it 
progresses  (e.g,,  determination  of  opera¬ 
tional  utility). 

In  fact,  the  fundamental  need  for 

continuing,  close  interaction  among  all  the 

2 

participants  in  the  C  system  acquisition 
process - -especially  the  provider,  user  and 


independent  tester- -is  basic  to  EA,  whereas 

3 

it  is  not  basic  under  P  I. 


3 

(4)  Finally,  EA  differs  from  P  I  in  several 
other  respects: 


-EA  demands  an  accelerated  and  abbreviated 
"requirements  process"  and  "procurement 
process"  leading  to  contractor  selection. 
This  is  necessary  to  enable  rapid  fielding 
of  a  "core"  and  subsequent  increments  so 
that  evolution  can  occur  based  on  feedback 
from  test  in  the  user's  environment. 


-Different  PPBS/budgeting  approach  arising 
from  less  initial  detail  on  the  ultimate 
total  program. 


-Differences  in  Program  Office  staffing, 
traditional  acquisition  is  "front-end 
heavy"  in  specialists  in  producibility , 
testing  and  ILS.  Under  E.^,  there  is 
essentially  a  continuous  need  for  all 
these  skills  but  in  a  more  "level-of- 


effort"  fashion, 


In  sum,  while  the  two  approaches  are 
incremental  and  have  a  number  of  similarities  in 
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form,  they  differ  significantly  in  front-end 
specification  and  implementation.  They  are 
distinctly  different  concepts. 


APPENDIX  D 
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Acquisition  Strategy 

a.  An  initial  program  acquisition  strategy  will  be 
developed  by  the  DoD  Ck>mponent  concerned  for  each 
major  system  acquisition  when  a  new  start  is  proposed. 
The  acquisition  strategy  should  be  tailored  to  the 
unique  circumstances  of  the  program.  Proposed 
exceptions  to  applicable  DoD  Directive  and 
Instructions  will  be  identified  in  the  acquisition 
strategy  as  it  evolves.  Advice  and  assistance  should 
be  sought  from  business  and  technical  advisors  and 
experienced  managers  of  other  major  system 
programs. 

b.  The  acquisition  strategy  is  the  conceptual  basis  of 
the  overall  plan  that  a  program  manager  follows  in 
program  execution.  It  reflects  the  management 
concepts  that  will  be  used  in  directing  and  controlling 
all  elements  of  the  acquisition  to  achieve  specific 
goals  and  objectives  of  the  program  and  to  enaire  that 
the  new  ^stem  satisfies  the  approved  mission  need. 
The  acquisition  strategy  encompasses  the  entire  acqui¬ 
sition  process  of  the  basic  system,  preplanned  product 
improvement  (P^I)>  and  post-production  support.  The 

strategy  must  be  developed  in  sufficient  detail,  at  the 
time  of  issuing  solicitations  for  the  concept 
exploration  phase,  to  permit  competitive  exploration 
of  alternative  system  design  concepts.  Sufficient 
planning  must  be  accomplished  for  succeeding  program 
phases,  that  involve  design,  competition,  provisioning 
and  support  economies,  and  production  source 
availability. 

c.  The  acquisition  strategy  must  evolve  through  an 
iterative  process  and  become  increasingly  definitive  in 
describing  the  interrelationship  of  the  management, 
technical,  business,  resource,  force  structure,  support 
testing,  equipment  standardization,  and  other  aspects 
of  the  program.  Normally,  the  baselining  and 
definition  of  a  program  will  progress  from 
establishment  of  operational  requirements  (JMSNS)  to 
functional  characteristics  (Milestone  I)  to  an  allocated 
functional  baseline  (Milestone  II)  to  a  production  base¬ 
line  (Milestone  IH). 

d.  Acquisition  programs  will  be  executed  with 
innovation  and  common  sense.  The  flexibility  inherent 
in  DoDD  5000.1  and  DoDI  5000.2  will  be  used  to  tailor 
an  acquisition  strategy  to  accommodate  the  unique 
aspects  of  a  particular  program,  as  long  as  the 
strategy  remains  consistent  with  the  basic  logic  for 
system  acquisition  problem  solving  and  good  business 
and  management  principles. 
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27.  Command  and  Control  cl  Systems. 

a.  The  types  of  systems  that  augment  the  decision¬ 
making  and  decision  executing  functions  of  operational 
commanders  and  their  staffs  in  the  performance  of  C^ 
require  a  tailored  acquisition  strategy.  The  principal 
characteristics  of  such  systems  are:  (1)  acquisition 
cost  normally  is  software  dominated;  (2)  the  system  is 
highly  interactive  with  the  actual  mission  users  and  is 
highly  dependent  on  the  specific  doctrine,  procedures, 
threat,  geographic  constraints,  and  mission  scenarios 
of  these  users;  and  (3)  these  ^sterns  are  characterized 
by  complex  and  frequently  changing  internal  and 
external  interfaces  at  multiple  oi^ganizational  levels, 
some  of  which  may  be  inter-Service  smd  multinational. 

b.  The  use  of  pre-planned  product  improvement  (P^l) 
is  a  procedure  highly  appropriate  to  such  systems  and 
should  be  considered  when  appropriate.  systems 
generally  require  an  evolutionary  acquisition  approach. 
This  is  an  adaptive,  incremental  approach  where  a 
relatively  quickly  fieldable  "core"  (an  essential 
increment  in  operational  capability)  is  acquired 
initially.  This  approach  also  includes  with  the 
definition  of  the  "core  capability";  (1)  a  description  of 
the  overall  capability  desired;  (2)  an  architectural 
framework  where  evolution  can  occur  with  minimum 
subsequent  redesign;  and  (3)  a  plan  for  evolution  that 
leads  towards  the  desired  capability. 

c.  Programming,  budget  approval,  and  acquisition 
management  must  be  tailored  to  encourage  and  enable 
early  implementation  and  field  evaluation  of  a  "core" 
system.  Subsequent  increments  must  be  based  on 
continuing  feedback  from  operational  use,  testing  in 
the  operational  environment,  evaluation  and  (in  some 
cases)  application  of  new  technology.  Operational  and 
interface  requirements  and  operational  utility  criteria 
should  be  evolved  with  the  participation  of  actual 
mission  users  (or  lead  user  and  appropriate  surrogate 
for  multi-user  ^sterns).  There  must  be  regular  and 
continual  interaction  with  developers,  independent 
testers,  and  logisticians. 
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d.  The  user  will  support  the  independent  T&E  agency 
in  determining  readiness  for  operational  use  of  the 
"core"  system  and  work  closely  with  the  development 
activity  and  independent  tester  in  evaluating 
subsequent  increments  of  new  technology.  A 
centralized  facility  will  be  used  to  accomplish  post 
deployment  software  support  of  fielded  increments 
under  centralized  configuration  management.  Consi¬ 
deration  must  be  given  to  the  use  of  existing 
commercial  equipment,  related  system  software  and 
firmware,  and  contractor  maintenemce  (with 
warranties)  whenever  logistic,  interoperability, 
readiness  considerations,  and  field  conditions  permit 
it. 


e.  Those  elements  of  systems  that  must  survive 
and  endure  in  strategic  or  theater  nuclear  warfare  will 
be  at  least  as  suryivable  as  the  weapon  system  they 
directly  or  indirectly  support.  A  proper  mix  of  survi¬ 
vability  techniques  must  be  applied.  Existing  military 
and  commercial  hardware,  software,  and  procedures 
should  be  used  only  if  it  can  be  demonstrated  that  they 
can  be  protected  against  and  made  resistant  to  wide- 
area  threats  such  as  jamming,  spoofing  and  electro¬ 
magnetic  pulse,  and  that  they  can  provide  reasonable 
functional/system/path  redundancy  against  direct 
attack  and  sabotage.  Interoperability  and  battlefield 
sustainability  will  be  key  considerations. 

f.  The  procedures  described  above  are  equally  appli¬ 
cable  to  similar  non-major  systems  as  well  as 
counter  -  C^,  electromagnetic  countermeasures,  and 
electronic  warfare  systems. 
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ELEMENTS  REPRESENTED  IN  FIGURE  3.1 
The  Tactical  Air  Control  Center  (TACC) 

The  TACC  is  the  senior  air  operations 
element  o£  the  TACS  and  functions  at  the  component 
level.  As  the  Commander's  operation  center/ command 
post,  the  TACC  provides  the  facility  and  personnel 
necessary  to  accomplish  the  planning,  directing  and 
coordinating  of  tactical  air  operations. 

Two  functions  form  the  core  of  the  TACC. 
They  are  housed  in  two  AN/TSQ-92  multi-cell 
inflatable  shelters.  Approximately  40  people  are 
required  to  assemble  and  wire  these  facilities  in  a 
24-hour  period.  An  additional  24  hours  is  normally 
required  to  achieve  operational  status. 

The  TACC  requires  approximately  350  people 
for  sustained  performance  of  all  functions:  plans, 
operations,  communications,  intelligence, 
maintenance,  and  liaison. 

Combat  Plans 


Combat  plans  compiles  and  manipulates  data 
on  aircraft,  aircrews,  electronic  combat  and  tanker 


support  and  munitions  availability;  targets, 
threats;  enemy  and  friendly  battle  orders;  weather; 
and  many  other  factors.  This  information  is  used  to 
build  an  ATO  which  satisfies  the  commander's  daily 
objectives  for  the  air  war.  The  normal  planning 
cycle  takes  36  hours  and  the  majority  of  the  work  is 
done  manually. 

Combat  Plans  is  supported  by  the  Army 
Battlefield  Combination  Element  (BCE)  and  Combat 
Intelligence  Division  (CID)  providing  Army  targeting 
priorities;  intelligence  on  enemy  and  friendly 
ground  situations,  targets,  threats;  and  order  of 
battle  information.  ATO  information  is  manually 
entered  into  the  CAFMS  which  compiles,  sorts,  and 
collates  the  data  into  standard  and  JINTACCS 
formats.  When  the  ATO  is  complete,  access  is 
granted  to  CAFMS  user  terminals.  Also,  a  paper  punch 
tape  is  cut  for  hard  copy  ATO  transmission  to  tasked 
units  not  possessing  CAFMS  terminals.  This  is 
transmitted  by  low-speed  teletype. 

Combat  Operations 

Combat  Operations  (Combat  Ops)  monitors  and 
coordintes  execution  of  the  ATO  and  incorporates 
both  defensive  and  offensive  air  operations 
functions.  Defensive  operations  monitors  the  air 


situation  and  controls  defensive  air  assets  by 
manual  greaseboard  plotting  and  by  displaying 
air/ground  radar  presentations  on  scopes  via  data 
link  from  air/ground/sea  radar  sites.  Offensive 
Operations  tracks  mission  progress,  coordinates 
mission  support  and  retargeting  using  plexiglas 
status  boards,  wall  maps  and  CAFMS. 

Combat  operations  is  supported  by  the  BCE 
and  Enemy  Situation  Correlation  Element  (ENSCE) 
providing  ground  situation,  threat  and  target 
priority  updates;  airspace  coordination;  and  joint 
operations  coordination.  ENSCE  supplies  the  most 
current  intelligence  available  for  adjusting  air 
operations  to  meet  changing  battlefield  requirements 
within  the  confines  of  the  commander's  objectives. 

Direct  Support  Unit  (DSUj 

The  DSU  is  a  unit  from  the  .A.ir  Force 
Electronic  Security  Command.  It  provides  the  TACS 
with  Communications  Security,  surveillance  support, 
support  to  electronic  communications,  and  other 
security  assistance. 

Control  and  Reporting  Center  CCRC) 

The  CRC  is  directly  subordinate  to  the  T.^CC 
and  is  the  primary  element  concerned  with 
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decentralized  execution  of  air  defense  and  airspace 
control  functions.  Within  its  area  of 
responsibility,  the  CRC  directs  the  region  or  sector 
air  defense  and  provides  aircraft  control  and 
monitoring  for  both  offensive  and  defensive 
missions.  It  relays,  as  directed,  mission  changes 
to  airborne  aircraft  and  coordinates  control  of 
missions  with  subordinate  TAGS  elements  and  other 
agencies,  as  necessary.  Inherent  in  these  functions 
are  the  requirements  to  supervise  subordinate  radar 
elements,  provide  threat  warning  for  friendly 
aircraft,  implement  procedures  to  ensure  that  air 
defense  assets  of  all  services  are  employed  in 
mutually  supporting  roles,  establish  coordination 
procedures  based  on  friendly  artillery  fire  plans, 
establish  the  means  for  air  traffic  regulation 
identification,  and  support  air  rescue  operations. 

Message  Processing  Center  (MFC) 

The  MFC  is  responsible  for  assuring  the 
automatic  transfer  of  tactical  data  over  digital  MFC 
data  links  between  elements  of  the  TAGS;  in  figure 
3.1,  between  the  MCF,  CRCs  and  the  AWACS. 


The  AWACS  is  an  airborne  radar  control 


element  of  the  TAGS.  It  has  the  ability  to  provide 
detection  and  control  of  aircraft  below  or  beyond 
the  coverage  of  ground-based  radar,  or  when 
ground-based  radar  elements  are  not  available.  The 
AWACS  radar  and  radio  coverage  permits  air  defense 
warnings,  aircraft  control,  navigational  assistance, 
coordination  of  air  rescue  efforts  and  changes  to 
tactical  missions. 

Air  Support  Operations  Center  (ASOC) 

The  ASOC  plans,  coordinates  and  directs 
immediate  tactical  air  support  of  ground  forces.  It 
is  subordinate  to  the  T.^CC  and  provides  fast 
reaction  to  immediate  requests  for  close  air 
support,  battlefield  air  interdiction,  tactical  air 
reconnaissance  and,  in  some  situations  tactical 
airlift.  The  ASOC  is  normally  collocated  with  a 
Corps  Tactical  Operations  Center  (CTOC)  but  may  also 
be  deployed  to  support  echelons  above  or  below 
corps.  .^n  ASOC  is  primarily  concerned  with  the 
exchange  of  combat  data  between  air  and  ground 
forces  concerning  the  planning,  coordination  and 
execution  of  immediate  tactical  air  support  of 
ground  operations.  Provisions  are  made  within  the 
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ASOC  for  G-2  (intelligence)  and  G-3  (operations) 
Army  air  representation  and  for  other  appropriate 
liaison  personnel,  as  required,  for  joint/combined 
operations . 

Wing  Operations  Center  (WOC) 

A  WOC  i-  a  Wing  Commander's  headquarters 
facility  which  includes  a  command  post,  command 
section,  battle  staff  and  other  planning  and  support 
elements  as  required.  Through  the  WOC,  the  Wing 
Commander  manages  and  controls  all  assigned/attached 
resources,  directs  operations  and  receives  orders 
and  combat  taskings  from  the  TACC.  A  WOC  is 
subordinate  to  the  TACC  and  functions  as  the 
operations  center  for  all  units  assigned/attached  to 
the  wing  for  operations. 

Corps  Tactical  Operations  Center  (CTOC) 

The  CTOC  is  the  Army  Corp's  main  command 
post.  The  ASOC  is  collocated  with  the  CTOC  to 
provide  direct  coordination  for  planning  and  control 
of  tactical  air  support. 

Computer  Assisted  Force  Management  System  (CAFMS) 

CAFMS  is  described  in  Chapter  III. 


-  o  * 


Display  and  Control/Storage  and  Retrieval 
CDC/SR)  System 
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The  DC/SR  provides  automated  assistance  for 
intelligence  collection  management,  target 
intelligence,  and  intelligence  data  base  management. 
The  system  is  housed  in  six  8'  x  8'  x  20'  vans  with 
associated  environmental  control  and  power 
equipment.  DC/SR  terminals  are  located  within  the 
AN/TSQ-92  facility.  Deployment  of  a  fully 
functional  DC/SR  facility  requires  six  C-141B 
sorties . 

Limited  Enemy  Situation  and  Correlation 
Element  CLENSCE) 

LENSCE  is  a  prototype  system,  operated  by 
the  9th  AF,  that  provides  automated  assistance  for 
intelligence  collection  management,  target 
intelligence,  and  other  tactical  fusion  functions. 
It  is  housed  in  two  8'  x  8'  x  20'  vans  with 
associated  support  equipment. 

Tactical  ELINT  Processor  CTEP) 

The  TEP  processes,  correlates,  and  reports 
electronic  intelligence  (ELINT).  The  system  is 
housed  in  an  8 '  x  8'  x  30'  trailer.  Associated 
terminals  are  located  within  the  AN/TSQ-92. 
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INTEGRATED  APPLICATIONS  SOFTWARE  SUITE 
GRiDManager 

GRiDManager  provides  a  variety  of  functions 
to  allow  the  user  to  manage  system  files,  sign-on 
and  sign-off  with  the  GRiD  Server,  duplicate,  erase, 
move,  and  exchange  files,  display  all  commands  with 
a  summary  of  their  functions,  and  display  or  print  a 
listing  of  files. 


GRiDWrite 

GRiDWrite  allows  the  user  to  edit  (full 
screen)  and  format  text.  Popular  uses  include 
letters,  memos,  and  other  document  generation. 

GRiDFile 

GRiDFile  is  a  relational  database 
management  system.  It  allows  the  user  to  store, 
retrieve,  sort,  display,  and  print  information  from 
its  two-dimensional  table.  Data  is  automatically 
saved  as  it  is  entered,  and  a  special  utility  helps 
the  user  to  recover  data  lost  in  the  database  due  to 
human  error. 


GRiDPlan 


GRiDPlan  is  an  electronic  spreadsheet 
similar  to  other  popular  commercial  spreadsheets. 
Basic  features  allow  the  user  to  perform  the 

following  functions: 

1.  Type  numbers  or  text  into  a  table. 

2.  Modify  the  table  without  complicated 
reformatting. 

3.  Define  formulas  to  calculate  values. 

4.  Perform  "what  if"  analysis. 

GRiDPlot 

GRiDPlot  displays  nximerical  data 
graphically.  From  data  contained  in  other  files  the 
user  can  choose  a  graph  format  Ci.e.,  clustered  bar, 


1. 
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Create  images. 

2.  Modify  files  created  with  GRiDPlot  or 
GRiDPaint's  Screenwatch  utility  program. 

3.  Type  text  using  typefaces  of  various  sizes 
and  styles. 

The  Computer-Assisted  Message  Generator  (CAM-G) 

CAM-G  is  a  custom  software  application 
that  allows  the  user  to  create  and  subsequently  fill 
in  a  pre-formatted  message  template  that  may  contain 
pre-set  optional  entries  for  each  blank  in  the 
template.  With  CAM-G  the  user  can  write  scheduled 
data  in  a  message  to  an  existing  database,  or  use 
data  in  a  message  to  update  data  in  an  existing 
database. 

The  Automated  Report  Generator  CARGEN) 

ARGEN  allows  the  user  to  design  and  create 
a  unique  display  of  selected  data  from  existing 
files . 


The  Electronic  Mail  System  (E-Mail) 

E-Mail  is  the  most  important  of  all 
applications,  as  it  allows  the  user  to  send 
information  automatically  to  another  user.  The 
sender  identifies  the  computer  addressee  unit  (and 
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recipient),  the  particular  communications  means 
Ce.g.,  single-channel  radio,  telephone,  etc.)>  mail 
precedence,  and  other  information,  and  sends  the 
file.  The  sender  receives  acknowledgment  when  the 
file  reaches  its  destination.  E-Mail  automatically 
notifies  the  recipient  of  the  incoming  "mail"  and 
its  precedence.  Mail  of  user  specified  precedence 
may  be  automatically  printed  upon  receipt.  The 
recipient  updates  the  database  with  the  received 
information,  as  necessary. 

The  Data  Automated  Video  Display  CDAViD)  System 

DAViD  allows  the  user  to  overlay 
information  from  a  database  on  map  backgrounds 
stored  on  a  videodisc  platter.  Information  is 
represented  on  the  map  in  the  form  of  predefined 
symbols  or  other  graphic  types,  such  as  lines, 
circles,  polygons.  DAViD  allows  the  user  to  point 
to  a  specific  graphic  symbol  to  "call  up"  more 
detailed  information  about  that  graphic  from  the 
database . 

The  database  containing  the  user's 
information  may  have  any  format,  though  at  least  one 
field  must  be  defined  to  contain  coordinates  in 
order  to  link  specified  information  to  map  location. 


.'y 


239 

Various  displays  can  be  created  by  placing 
conditions  on  the  displayed  data  or  by  turning  on  or 
off  specific  data  to  display.  These  overlay 
pictures  can  then  be  saved  for  later  retrieval. 


APPENDIX  G 


LETTER  FROM  MAJOR  GENERAL  BRECKNER 
TO  GENERAL  DONNELLY 


DEPARTMENT  OF  THE  AIR  FORCE 
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30  May  1985 


General  Charles  L-  Donnelly 
CINCUSAFE 

Dear  General  Donnelly 

As  you  may  recall  from  your  recent  visit  to  ATOC  Sembach  during 
WINTEX-CIMEX  85,  we  have  been  investigating  a  number  of 
approaches  to  enhancing  joint  air-ground  operations  and  providing 
a  means  for  better  coordination  between  the  air  and  ground 
commanders.  During  your  visit,  you  saw  some  of  the  capabilities 
of  DNA  and  USAREUR  developed  software  on  CORVUS  computers.  This 
prototype  system,  called  the  USAREUR  Distributed  Decision  Aid 
System  (UDDAS),  appears  to  hold  great  promise  for  near  term 
improvement  to  our  operations- 

The  UDDAS  system  is  being  fielded  throughout  USAREUR  (V  and  VII 
(US)  Corps)  and  CEMTAG.  Gen  Otis  and  his  staff  have  been  very 
cooperative  in  helping  us  understand  the  attributes  and 
capabilities  of  the  system.  In  a  recent  development,  a  joint  US 
State  Department  approved  technology  agreement  was  signed  between 
the  US  BDM  Corporation  (which  developed  the  software)  and  the 
German  Diehl  Corporation  to  put  the  software  on  their  computers. 
This  should  open  the  way  for  even  greater  proliferation  of  UDDAS 
capabilities  among  allied  nations- 

We  think  that  the  UDDAS  system  can  enhance  our  ability  to  conduct 
the  air  battle-  We  are  proposing  to  adopt  the  UDDAS  system  at 
the  ATOC  to  provide  us  automated  connectivity  and  data  transfer 
capability  to  bridge  the  air  to  ground  coordination  gap.  A 
talking  paper  on  this  proposed  plan  is  attached  (Atch  1).  The 
end  goal  must  naturally  be  bridging  the  gap  at  all  levels  of 
command  where  physical  co-location  as  realised  by  AATAP/CENTAG  is 
not  possible-  It  is  with  this  thought  that  I  enjoin  you  to  give 
us  your  support  both  from  a  US  national  position  as  well  as  from 
COMAAFCE  to  bring  in  AAFCE  and  the  ATAFs  as  part  of  the  whole 
scheme . 

During  Exercise  CENTRAL  ENTERPRISE  we  will  be  concluding  our 
initial  investigation  of  the  system  in  the  ATOC.  I  am  Inviting  V 
Corps  Commander,  Lt  Gen  Wetzell,  and  MGen  Todd  and  his  staff  to 
visit  the  ATOC  and  discuss  these  initiatives.  During  this  period 
we  also  intend  to  conduct  limited  battle  management  of  SOC  III 
operations  from  within  the  ATOC.  I  propose  to  show  them  the 
UDDAS  operation  and  discuss  this  and  other  initiatives  to  improve 
our  joint  battle  capabilities.  Your  approval  and  support  in 


2 


these  efforts  is  essential  to  accomplishing  our  goals.  We  stand 
ready  to  provide  any  additional  Information  or  support  you  may 
require. 


Very  respectfully 


7 

JR., 


Maj  Gen,  USAF  1  Atch 

Talking  paper  on  Near 
Term  Air-Ground 
Command  and  Control 
System  Plan 
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CN 

A  NEAR  TERM 

AIR-<3R0UND  COMAND  AND  CXDOTBOL  SYSTEM 
PLAN 


PROBLEM 

-Hiere  is  currently  no  autcnated  oamrunications/data  system  that  crosses  the 
air  to  ground  boundaries  and  ties  in  the  essential  elements  of  land-air 
battle  coordination. 

BACKGROUND 

-Recent  studies  hi^light  serious  deficiencies  vAiich  will  still  exist  within 

2 

the  NATO  air-ground  C  environment  even  vihen  the  current  infrastructure  is 

ocnpleted.  Some  of  these  deficiencies  include  limited  ability  to  coordinate 

detection,  targeting  and  attack  of  mobile  time-sensitive  targets  and  ncn- 

2 

existent  or  severely  limited  automated  C  systems  between  air  and  ground 
battle  oonnanders. 

2 

-U5ARCUR  has  initiated  a  program  to  provide  an  autonated  C  system  throughout 

the  ground  battle  elements.  The  USAREUR  Distributed  Decision  Aid  System 

(UDDAS)  was  initially  deployed  in  Exercise  WINTQC-CIMOC  84.  During  Exercise 

WINTEX-CIMBC  85#  the  system  was  eigaanded  to  CQn'AG/4AI?\F  elements  to 

establi^  connectivity  between  CENTAG  and  its  four  Corps,  ihe  system  was 

also  deployed  with  ATOC  Sembach  (ATCXI(S))  as  a  first  step  in  providing  air- 
2 

ground  C  connectivity  and  coordination.  With  this  currently  fielded  system# 

2 

the  potential  exists  to  extend  autonated  C  connectivity  to  NATO  and  national 
systems  in  the  very  near  future. 
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DISCUSSION 

-11)6  UIX3^S  system  Viias  designed  as  a  ccnnend  and  oontrol  nebiork  based  on  the 
concept  of  a  dispersed  carnrand  post.  The  eystem  enplcys  an  autonated 
distributed  processing  scheme  which  allows  key  elements  to  be  "electronically, 
oo-located"  with  other  key  elements  to  form  a  total  comiBnd  and  control 
function.  Infomation  can  be  displayed  in  data  formats  as  well  as  color 
graphic  foznats,  reducing  the  time  necessary  to  interpret  volumes  of  data. 

All  data  bases  eure  replicated  at  each  node  so  if  a  given  node  is  lost,  other 
nodes  are  not  affected.  Each  node  has  a  stand-alone  capability  and  the 
softMzure  to  perform  all  functions,  ihe  system  can  interface  «d.th  nultiple 
other  systems  and  provide  for  eiqpansion  into  the  networks  of  these  systems. 

-The  UDDAS  systems  offers  the  following  essential  inprovements  to  ATOC/SOC 
current  operations 

— Autonated  displays  replacing  grease  boards 


— Infomation  and  battle  data  exdiangs  between  4ATAP/CQnAG  and  siipported 


corps  ("single  sheet  of  nusic") 

— Redundancy  to  EIFEL 
— Easing  of  message  center  traffic  jam 
— Automated  oocmunications  over  nultiple  ocnin  means 

!  — Interface  with  other  automated  systems 

i 

I 

i 


-The  approach  to  fielding  such  an  operational  system  is  proposed  to 
capitalize  on  the  USAREUR  initiative  and  provide  a  oonpanion  effort  among  the 
air  elements  of  AAPCE  using  an  evolutionary  development  approach.  The 
proposal  should  be  inplemented  in  phases  to  derive  naxinum  benefits  and 
planning. 
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— I^se  Z.  Ccnduct  limited  ejq^rimmts  during  pleuined  exercises  to 
demonstrate  capabilities  and  attributes.  This  was  essentially  acocnplished 
in  WI^^^E}C-CIMEX  85  and  should  be  concluded  in  CENTRAL  QTTERPRISE  85. 

(Timing  -  now) 

— Ihase  II.  Field  an  cperational  prototype  using  existing  equipment 
connected  with  real-time  oonnunication  links  to  4AIAF/CQn'AQ,  KTOC/SOC,  and 
V  and  VII  (US)  Corps.  (Timing  -  next  6  mos.) 

— Piase  III.  Let  a  oontract  to  enhance  system  software  as  required,  provide 
interface  %d.th  EIFEL,  and  field  additional  nodes  to  include  mobile  TAGS, 
and  32  AACOCM.  (Timing  -  ASAP  upon  ocnpletion  of  Ehase  II. ) 

— Riase  IV.  l]|pgrade  hardware  and  finalise  network  d^lcyment  to  provide  an 
operational  system.  Initiate  formal  definition  for  oapahilities/attributes 
of  a  follaw-<xi  system.  (Timing  -  within  12  mos. ) 


GONCLUSION 

-An  effective  air-ground  oonmand  and  control  system  «Aiich  provides  an 
integrated  ooninon  peroqjtion  of  the  total  battle  situation  can  be  established 
using  existing  capabilities  of  the  UDDAS  Qystenu  Throucb  interface  of  UDDAS 
%d.th  EIEEL  and  other  C  systems  at  hardened  facilities  such  as  the  A3QC, 
redundancy  and  survivability  of  all  systems  can  be  enhanced.  The  technology 
and  heundumre  are  available  now  at  low  cost.  An  operational  ^stem  can  be 
ocnpleted  in  the  very  near  term. 

REXXYMENDATICN 

-Seventeenth  Air  Force  should  inplement  this  plan  for  ATOC  Senbach  and  SOC  III 
activities:  Additicxially,  USAFE  and  AAFCE  should  be  enjoined  to  oonplement 
this  initiative  with  similar  a<rtions  for  HQ  AAFCE  and  4ATAF.  Such  actions 


246 


ccnbined  with  the  USAREUR  initiative  will  provide  a  fully  cperaticxial  system 
for  the  southern  sector  of  the  Guropean  Central  Region.  A  parallel  effort 
for  the  northern  sector  would  logically  follow  suit. 


DEPARTMENT  OF  THE  AIR  FORCE 

HEADOUABTERS  seventeenth  air  force  (USAFE) 
APO  NEW  VOBX  0T1M 
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30  May  1985 


General  Charles  L-  Donnelly 
CINCUSAFE 

Dear  General  Donnelly 

As  you  may  recall  from  your  recent  visit  to  ATOC  Sembach  during 
WINTEX-CIMEX  85,  we  have  been  investigating  a  number  of 
approaches  to  enhancing  joint  air-ground  operations  and  providing 
a  means  for  better  coordination  between  the  air  and  ground 
commanders.  During  your  visit,  you  saw  some  of  the  capabilities 
of  DNA  and  USAREUR  developed  software  on  CORVUS  computers.  This 
prototype  system,  called  the  USAREUR  Distributed  Decision  Aid 
System  (UDDAS),  appears  to  hold  great  promise  for  near  term 
improvement  to  our  operations - 

The  UDDAS  system  is  being  fielded  throughout  USAREUR  (V  and  VII 
(US)  Corps)  and  CEMTAG.  Gen  Otis  and  his  staff  have  been  very 
cooperative  in  helping  us  understand  the  attributes  and 
capabilities  of  the  system.  In  a  recent  development,  a  joint  US 
State  Department  approved  technology  agreement  was  signed  between 
the  US  BDM  Corporation  (which  developed  the  software)  and  the 
German  Diehl  Corporation  to  put  the  software  on  their  computers. 
This  should  open  the  way  for  even  greater  proliferation  of  UDDAS 
capabilities  among  allied  nations- 

We  think  that  the  UDDAS  system  can  enhance  our  ability  to  conduct 
the  air  battle-  We  are  proposing  to  adopt  the  UDDAS  system  at 
the  ATOC  to  provide  us  automated  connectivity  and  data  transfer 
capability  to  bridge  the  air  to  ground  coordination  gap.  A 
talking  paper  on  this  proposed  plan  is  attached  (Atch  1).  The 
end  goal  must  naturally  be  bridging  the  gap  at  all  levels  of 
command  where  physical  co-location  as  realized  by  4ATAF/CENTAG  is 
not  possible  It  is  with  this  thought  that  I  enjoin  you  to  give 
us  your  support  both  from  a  US  national  position  as  well  as  from 
COMAAFCE  to  bring  in  AAFCE  and  the  ATAFs  as  part  of  the  whole 
scheme . 

During  Exercise  CENTRAL  ENTERPRISE  we  will  be  concluding  our 
initial  investigation  of  the  system  in  the  ATOC.  I  am  inviting  V 
Corps  Commander,  Lt  Gen  Wetzell,  and  MGen  Todd  and  his  staff  to 
visit  the  ATOC  and  discuss  these  initiatives.  During  this  period 
we  also  intend  to  conduct  limited  battle  management  of  SOC  III 
operations  from  within  the  ATOC.  I  propose  to  show  them  the 
UDDAS  operation  and  discuss  this  and  other  initiatives  to  improve 
our  joint  battle  capabilities.  Your  approval  and  support  in 


these  efforts  is  essential  to  accomplishing  our  goals.  We  stand 
ready  to  provide  any  additional  Information  or  support  you  may 
require. 

Very  respectfully 


1  Atch 

Talking  Paper  on  Near 
Term  Air-Ground 
Command  and  Control 
System  Plan 
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TAUaNG  PAPER 
CM 

A  NEAR  TERM 

AIR-GROUND  CX>MAND  AND  CONTROL  SYSTEM 
PLAN 


PROBLEM 

-niere  is  currently  no  autonated  oonnunications/data  system  that  crosses  the 
air  to  ground  boundaries  and  ties  in  the  essential  elements  of  land-air 
battle  coordination. 

BACKGROUND 

-Recent  studies  hi^li^t  serious  deficiencies  %Aiich  will  still  exist  itdthin 

the  NATO  2dr-ground  C  environment  even  vAien  the  current  infrastructure  is 

ocnpleted.  Some  of  these  deficiencies  include  liadted  ability  to  coordinate 

detection,  targeting  and  attadc  of  nobile  time-sensitive  targets  and  non- 

2 

existent  or  severely  limited  autonated  C  systems  between  air  and  ground 
battle  ocnnanders. 

2 

-USAREUR  has  initiated  a  program  to  provide  an  automated  C  system  throughout 

the  ground  battle  elements.  The  USAREUR  Distributed  Decision  Aid  System 

(UDDAS)  was  initially  deployed  in  Exercise  WINTQC-CIMDC  84.  During  Exercise 

WINTDC-CIMOC  85,  the  system  was  eiqsanded  to  CE2n!AG/4A!IAF  elements  to 

establish  connectivity  between  CENTAG  and  its  four  Corps.  The  system  was 

also  deployed  with  ATOC  Senbach  (ATOC(S)}  as  a  first  step  in  providing  air- 
2 

ground  C  connectivity  and  coordination.  With  this  currently  fielded  system, 

2 

the  potential  exists  to  extend  automated  C  connectivity  to  MATO  and  national 
systems  in  the  very  near  future. 
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DISCUSSIC3N 

-The  UDIAS  system  was  designed  as  a  cxsmand  cind  cxsitrol  network  based  on  the 
concept  of  a  dispersed  ccrnand  post.  The  system  enploys  an  autorated 
distributed  processing  scfherae  which  allows  key  elements  to  be  "electronically, 
oo-located"  with  other  key  elements  to  form  a  total  connand  and  control 
function.  Infomation  can  be  displayed  in  data  formats  as  well  as  color 
graphic  formats,  reducing  the  time  necessary  to  interpret  volumes  of  data. 

All  data  bases  are  replicated  at  each  node  so  if  a  given  node  is  lost,  other 
nodes  are  not  affected.  Each  node  has  a  stand-alone  capability  and  the 
software  to  perform  all  functions.  The  system  can  interface  %^th  nultiple 
other  systems  and  provide  for  expansion  into  the  networks  of  these  systems. 

-The  UDDA5  systems  offers  the  following  essential  Inprovements  to  KtOC/SCC 
current  operations 

— Autcnated  displays  r^lacing  grease  boards 

— Infarmaticn  and  battle  data  exchange  between  4ATAF/CXNIAG  and  sipported 
corps  ("single  sheet  of  nusic") 

— Redundancy  to  EIEEL 
— Easing  of  message  center  traffic  jam 
— Autcnated  oomrunications  over  nultiple  ocnrn  means 
— Interface  with  other  automated  systems 

-The  approach  to  fielding  such  an  cperational  ^stem  is  pixposed  to 
capitalize  on  the  USAREUR  initiative  and  provide  a  ocnpanion  effort  among  the 
air  elements  of  AAFCE  using  an  evolutionary  development  approach.  The 
proposal  should  be  implemented  in  phases  to  derive  naxitaon  benefits  ^md 
planning. 


— I^iase  I.  Conduct  limited  experiments  during  pl2uined  exercises  to 
demonstrate  capabilities  and  attributes.  Ibis  was  essentially  acocnplished 
in  WUTTEX-CIMCX  85  and  should  be  concluded  in  CENTRAL  ENTEllPRISE  85. 

(Timing  -  now) 

— Ib2ise  II.  Field  an  cperational  prototype  using  existing  equipment 
connected  with  real-time  oomiunicaticn  liidcs  to  4AXAP/CQn'A6«  ATCX;/SOC,  and 
V  and  VII  (US)  Corps.  (Timing  -  next  6  mos.) 

— {base  III.  Let  a  contract  to  enhance  system  software  as  required,  provide 
interface  vdth  EIFEZ,,  and  field  additional  nodes  to  include  mobile  TAGS, 
and  32  AADOGM.  (Timing  -  ASAP  iqxn  oonpletion  of  Ebase  II. ) 

— Ibase  IV.  hardi«are  and  finalise  network  dqplcyment  to  provide  an 

operational  system.  Initiate  f<%nal  definition  for  oapabilities/attributes 
of  a  follow-on  system.  (Timing  -  within  12  mos. ) 

C0NCLU5ICN 

-An  effective  air-ground  ccnmand  and  control  system  tdiich  provides  an 
integrated  ooRinan  perc^Jtion  of  the  total  battle  situation  can  be  established 
using  existing  capabilities  of  the  UDDAS  System.  Tbrouglh  interface  of  UDDAS 
vdth  EIFEL  and  other  C  systems  at  hardened  facilities  such  as  the  KTOC, 
redundancy  and  survivability  of  all  systems  can  be  enhanced.  The  technology 
and  hardumre  are  available  now  at  low  cost.  An  cperaticxial  system  can  be 
cxxipleted  in  the  very  near  term. 

RB0QM1ENDATICN 

-Seventeenth  Air  Force  should  inplement  this  plan  for  ATOC  Senbach  and  SOC  III 
activities;  Additionally,  USAFE  and  AAFCE  should  be  enjoined  to  cxxiplenent 
this  initiative  with  similar  actions  for  HQ  AAFCE  and  4ATAF.  Such  actions 


oczrbined  with  the  USAREUR  initiative  will  provide  a  fully  cperational  system 
for  the  southern  sector  of  the  European  Central  Region.  A  parallel  effort 
for  the  northern  sector  would  logically  follow  suit. 


12635  Scarsdale,  Apt.  112 
San  Antonio,  Texas  78217 


6  January  1986 


Major  Raymond  C.  Harlan 

Program  Manager,  Special  Programs  Division 
Air  Force  Institute  of  Technology 
Wright-Patterson  Air  Force  Base,  Ohio  45A33-6583 


Enclosed  is  one  unbound  copy  of  my  research  report.  As  discussed 
with  Ms.  Reed  today,  I  have  sent  one  bound  copy  to  Air  University 
Library.  Suggested  key  words  for  use  by  the  Defense  Technical 
Information  Center  are  attached. 

I  would  like  to  express  my  appreciation  to  you  and  Ms.  Reed  for 
making  my  experience  in  AFIT  both  enjoyable  and  relatively 
headache  free.  If  I  can  assist  you  at  any  time,  please  do  not 
hesitate  to  give  me  a  call. 


Sincerely, 


rles  J.  Boensch 
Captain,  USAF 
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